Hi John, thanks for the response. Comments inline: On Sep 19, 2012, at 3:45 AM, John C Klensin <john-ietf@xxxxxxx> wrote: > > > --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. I understand this part, and I think the general "no satisfactory solution other than a forklift upgrade" problem is reasonably we doll expressed. My personal feelings are that downgrading is likely to cause more harm than good--but I'm willing to accept that the working group is in a "can't please everyone (if anyone)" situation, and considered it a reasonable enough option to document it. But... (see next) > > 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. I have trouble seeing how discussing the known issues (including the out-of-band one you just mentioned) would be misleading. I realize the wg can't come up with one-size-fits-all guidance. But one of the purposes of the security considerations is to document issues that implementors and deployers need to think about, even if it doesn't tell them the answers. I'm mostly agnostic about where this sort of information goes. 5738bis does mention the potential problem, but offers little guidance beyond "extreme care". I do see some value in putting it in the drafts that actually talk about the details of modifying content. > > 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. My concern here is that 5738bis doesn't really say that. It take more the approach of saying "you really should forklift upgrade. Really. We mean it. But if you must do downgrading, where's some examples[informational references]" If the downgrade docs are really to be considered standards, then wouldn't it make more sense to treat these as a normative reference, and strengthen the language to say "if you must do downgrades, here are the two best alternative approaches [Normative Reference]"? I further note that 5721bis has a normative reference to section 7 of 5738bis for this very purpose, but that's diluted by lack of normative reference do the downgrade drafts in 5738bis. > > 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. Now, that argues the exact opposite than the previous paragraph, doesn't it? That points more to like "you really shouldn't downgrade. But if you must, here's some example approaches", and making the downgrade docs informational. (For that matter, since the only consumers of downgraded content will be clients that don't implement these drafts, is there any reason to standardize downgrading at all? We're not talking about interoperability here, are we?) > > best, > john >