Thanks for the response--comments inline: On Sep 19, 2012, at 10:18 AM, Arnt Gulbrandsen <[email protected]> wrote:
> 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. I make no assumptions about whether the modification is persistent in the mail drop. The message as delivered to the client, which is where the end user actually reads it, is modified. > > 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. My point is that I believe the potential issues caused by the modification of signed content should be covered in more depth. You mention the problem, which is good. I'm not proposing normative guidance, but there's a lot an implementor and deployer should think before breaking signed content. For example, could they strip signatures? Put in warnings that explain the reason a signature cannot be verified? Verify locally and resign the modified version (along with a statement about what happened)? Ignore the problem because their users never do S/MIME anyway? Even if the draft offers no answers, I think it needs to offer more guidance about issues that the reader needs to think about and draw conclusions from. > > 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. Ah, that's a better explanation than I've seen so far :-) > >> -- 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. > Thanks--It's been a while since I worried about IMAP protocol details. The fact that the actual downloaded content size is expressed elsewhere makes this less of a concern. (And adding the proposed reminder would help other's avoid the same mistake :-) ) >> -- "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. Do you consider the open issue called out in the draft to be resolved, then? OTOH, this highlights a concern I didn't think about when reviewing the other draft, which is a user agent unaware of the UTF8 updates is unlikely to present new, unknown headers to the end user. I don't know if the error code is more likely to be presented. (I will comment on that in the thread specific to that draft.) > >> -- 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. It's standard RFC editor procedure. The abstract is often presented separate from the rest of the draft, and the draft headers. [...]
