Subject: [Gen-art] Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Sep 2012 21:24:48 -0500

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.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Sep 2012 04:45:28 -0400

--On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell
<[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For
> background on Gen-ART, please see the FAQ at
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> -- 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 19 Sep 2012 17:18:24 +0200

On 09/19/2012 04:24 AM, Ben Campbell wrote:
> -- 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.

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

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.

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

> 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-do…

OK.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Sep 2012 14:30:47 -0400

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

There's no need to be flippant; this is called out by the idnits
program, and Ben is highlighting it.  It's not a big deal, but there
are reasons for it:

1. The "updates" (and "obsoletes") information is not in the text of
the published RFC, but is part of the RFC's metadata.  Not everyone
who will look at the RFC will see the metadata.  Some will see only
Title and Abstract.  And so on.  It's not just frivolity to put
something in the Abstract.

2. We also like to have an *explanation* in the Introduction, saying
why a document updates another.  For that part, it's not just "This
document updates RFC 3501," but "This document updates RFC 3501
because it adds [this] and changes [that]."

Barry

---

From: Ned Freed <[email-masked]>
Date: Thu, 20 Sep 2012 11:30:38 -0700 (PDT)

> > -- I'm concerned about the security considerations related to having a
> > mail drop modify a potentially signed message.
> ...

> has the valid signature? If not I suppose extra verbiage is needed.

I think this is already pretty clear: The texts says things like "present"
and "serve". It takes a pretty deliberate misreading to miss those words.

Moreover, stating that this "happens only in RAM" may not be correct. A server
could choose to store a downgraded version so it doesn't have to be rerendered,
for example. The point is that version isn't going to be presented to a client
that supports EAI, not that it only happens in RAM.

> there will be damage is expected and accepted. IMO it's unavoidable.

I think that's more a matter of fact, not opinion. If your software is
incapable of presenting something, it's incapable of presenting something.
The only question is whether you get a downgraded version the software is
capable of handling or nothing. EAI allows that choice to be made by
the implementation or operationally.

> download was reported as 42kb, that's all. I wish all my problems were

If it's exploitable it almost certainly is what I refer to as the "tiny twig on
the attack tree". That is, if there's a size-related issue there are going to
be much easier ways to exploit it than this.

I suppose some folks may believe that describing these sorts of twigs is 
valuable. I disgree and believe it to be unncesssary clutter that is likely to
end up detracting from overall security.

> header fields, why then bother with the DOWNGRADED response code? But

I agree it doesn't matter.

> document, that's hardly what I would expect to see in a single-paragraph

Exactly right. This is a silly thing to do.

> email body text. Just in case I didn't see it the first time, I suppose.

The policy for EAI documents, which was agreed to by the working group and
which is now reflected in a number of RFCs, is not to put this sort of nonsense
in the abstract.

				Ned

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Sep 2012 14:33:05 -0500

Hi John, thanks for the response. Comments inline:

> very concerned if such a check (signature-based or otherwise)

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)

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

> implement downgrading this way" is by putting those documents on

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.

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Sep 2012 14:58:32 -0500

Thanks for the response--comments inline:

On Sep 19, 2012, at 10:18 AM, Arnt Gulbrandsen <[email-masked]> wrote:

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

Ah, that's a better explanation than I've seen so far :-)

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

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

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

[...]