On 09/19/2012 04:24 AM, Ben Campbell wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-eai-simpledowngrade-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20
Summary: This draft is mostly on the right track, but has open issues
Major issues:
-- I'm concerned about the security considerations related to having a mail drop modify a potentially signed message.
...
Hm, sounds like a misunderstanding. Did you understand that the
modification happens in RAM, and that the message stored unmodified and
has the valid signature? If not I suppose extra verbiage is needed.
The signature issue has been discussed. The answer is more or less: The
WG expects EAI users to use EAI-capable software, and to accept partial
failure when using software that cannot be updated.
This entire draft is draft is about damage limitation when an EAI user
uses EAI-ignorant software (e.g. your phone, if you do your main mail
handling on a computer but occasionally look using the phone). That
there will be damage is expected and accepted. IMO it's unavoidable. The
WG tries to ensure that the damage is not permanent (in the same
example: so you can still read the mail, properly signed and addressed,
on your computer).
FWIW, I mangled a message by hand to see what happened to a signature,
and got an angry-looking complaint above the body text. Or maybe it was
above the headers. Whatever.
Minor Issues:
-- It's not clear to me why this is standards track rather than informational.
I don't remember. Perhaps because it needs to update 3501.
-- section 3, 2nd paragraph:
Are there any limits on how much the size can differ from the actual delivered message? Can it be larger? Smaller? It's worth commenting on whether this could cause errors in the client. (e.g. Improper memory allocation)
An input message can be constructed to make the difference arbitrarily
large. For instance, just add an attachment with a suggested filename of
a million unicode snowmen, and the surrogate message will be several
megabyte smaller than the original. Or if you know that the target
server uses a long surrogate address format, add a million short Cc
addresses and the surrogate will be blown up by a million long CC addresses.
I doubt that this is exploitable. You can confuse or irritate the user
by making the client say "downloading 1.2MB" when the size before
download was reported as 42kb, that's all. I wish all my problems were
as small.
I'll add a comment and a reminder that the actual size is supplied along
with the literal during download.
-- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also mention DOWNGRADED?"
Good question. It seems like they should be consistent on things like this. (This is really more a comment on that draft than this one.)
I think I've made up my mind that in this case it doesn't matter.
Kazunori's task is complex reversible downgrade and has the Downgraded-*
header fields, why then bother with the DOWNGRADED response code? But
it's not my decision.
-- Abstract should mention that this updates 3501
Really? A detail of this document updates a minor detail of that
document, that's hardly what I would expect to see in a single-paragraph
summary.
I know someone who likes to repeat the Subject in the first line of the
email body text. Just in case I didn't see it the first time, I suppose.
-- section 1:
Can you more explicitly define "conventional"? I assume this means clients not supporting the relevant UTF8 capabilities? This terminology is inconsistent between this and draft-ietf-eai-popimap-downgrade.
OK.
Arnt