Hi John, thanks for the response. Comments inline:
On Sep 19, 2012, at 3:45 AM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
--On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell
<ben(_at_)nostrum(_dot_)com> 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