--On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell <ben@xxxxxxxxxxx> 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. The > draft mentions that this is an issue. I think more discussion > is warranted. In particular. What client behavior is expected > when a signature is invalidated due to downgrading? I suspect > the answer is "warn the user, who will most likely just click > through without understanding the issue." I'm concerned about > adding yet another reason to train end users to ignore > security warnings. OTOH, should the mail drop strip out > signatures? That has it's own issues. I'm not saying that I > know the answer--merely that it's not clear to me that it has > been sufficiently explored. Ben, I want to respond as WG Co-chair to this one issue. Comments on your minor issues will follow, but please be assured that the non-editorial ones (and even some of those) have been discussed extensively in the WG. There is a fundamental issue that runs across the four documents, that the WG discussed extensively, and that the WG believes is adequately described. The WG made an explicit decision to not repeat that explanation at every possible point and in each document. It explicitly chose overall brevity over repetition partially in the belief that repeating the material might cause important comments or requirements to get lost in the noise. At the same time, it is easy to lose sight of the issue and its implications when reviewing the documents. It actually becomes very clear when one starts considering implementation details. That issue is that a upgraded IMAP or POP server may find itself in possession of an message that requires SMTPUTF8 ("EAI") capability, that it may be one message of that type among many messages with ACSCII-only headers that do not require that capability, and that it may find itself connected to by a legacy client. There are two important things about that case: * There is absolutely no way to deliver the problem message to the client. The IMAP and POP specifications, and the basic email transport and header specifications from which their provisions are derived, are absolutely clear that addresses and header fields are in ASCII (IMAP allows for the use of some alternate character sets and encodings, but that turns out to be a bad choice in this case and, fwiw, conversion to use any of them would also invalidate signatures. * There are no provisions in POP or IMAP for the server to say to the client "this particular message fails within the range you have specified, but cannot be delivered to you" (much less why that is the case). In principle, EAI could have added such capabilities but they would not haved helped legacy clients (that, by definition, didn't implement them), would have added clutter to the protocols, and would not have benefited upgraded clients either (because it is easier to just support UTF-8 headers and other requirements. Given that situation, the POP or IMAP server can choose to do any of a range of things, all of them bad news. Two of the choices are to _replace_ the original message with a substitute (or "synthetic" or "surrogate") message that provides the user of the client some more or less good hints about what is going on and what the original message was about. What is being delivered is not the original message. If the original contained non-ASCII addresses, the surrogate will not be able to represent them directly and will, in general, not be reply-able. Expecting an integrity check on the original message to be valid with the surrogate one is unreasonable; indeed, one would be very concerned if such a check (signature-based or otherwise) did validate. When there is an integrity check present, perhaps the Right Thing would be to disable it and include a note in the surrogate message that indicates that the original contained such a check. The wording was intended to allow for that option when it is deemed appropriate and feasible by the server's designers and operators. But remember that there are undetectable cases (not covered specifically by IETF standards) such as when the signature or equivalent information is transmitted out of band. The net result of this is that saying much more in the Security Considerations section would be likely to be misleading, covering some cases and not others. And, to answer your specific question above, the WG did consider the issue and the various cases and alternatives, and did so at great length. The complexity of the situation also explains the choice of standards track for the two downgrade specs. On the one hand, as you note, the POP and IMAP specs are written primarily from the standpoint of an upgraded server talking to an upgraded client. We expect that to be the long-term situation and it is the right way to write the specs given that situation. Because of the many options as to what to do in this transitional case, a normative reference to one or more specific ones would have been inappropriate. On the other hand, while the two strategies represented by popimap-downgrade and simpledowngrade are believed by the WG to be self-consistent and adequate given the assumptions identified for them, there are _many_ ways to get things wrong (some of which the WG discovered only after considerable discussion). The only way we have to clearly say "if you are going to make these decisions and assumptions, then implement downgrading this way" is by putting those documents on standards track. As I hope it clear from the above, the WG has strong consensus that the only correct and completely adequate solution to the problem of an upgraded server interacting with a legacy client over a message that requires those upgraded capabilities is to avoid having the problem occur by getting an upgraded client. We could write more explicit applicability language to say that, but, IMO and that of the WG, it wouldn't contribute anything. best, john