Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

Ben Campbell-3
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.

Minor Issues:

-- It's not clear to me why this is standards track rather than informational. As far as I can tell, it's mainly used by the IMAP UTF8 capability draft. But that draft seems to list this as an example of something you can do, and lists it as an informational reference.

-- 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)

-- "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.)


Nits and Editorial Comments:

-- This draft appears to dispense with 2119 language. It be nice if all the drafts in the group handled this consistently.

-- Abstract should mention that this updates 3501

-- 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.


_______________________________________________
Gen-art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/gen-art
Reply | Threaded
Open this post in threaded view
|

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

John C Klensin


--On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell
<[hidden email]> 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

_______________________________________________
Gen-art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/gen-art
Reply | Threaded
Open this post in threaded view
|

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

Arnt Gulbrandsen
In reply to this post by Ben Campbell-3
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

_______________________________________________
Gen-art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/gen-art