Subject: [apps-discuss] Fwd: Review of draft-ietf-eai-simpledowngrade-03

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2012 09:23:28 -0700

Apologies; I forgot to cc this list on the review.

regards,

Ted

---------- Forwarded message ----------
From: Ted Hardie <[email-masked]>
Date: Mon, Apr 23, 2012 at 8:57 AM
Subject: Review of draft-ietf-eai-simpledowngrade-03
To: [email-masked]
Cc: IESG <[email-masked]>

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Ted Hardie
Review Date: April 23, 2012

Summary: I believe that the draft is almost ready for publication, but
that it cannot be progressed on the standards track because of its
impact on the security of the email messages.  I understand the
reluctance of the WG to create Experimental documents at this stage,
so I suggest Informational as a target status.

Major Issues:

The document is clear that its intent is to provide a
simple-to-implement method that provides basic means for downgrading
certain fields in a message.   A major element of its strategy is to
silently excise information which cannot be presented to the user.
This may eliminate MIME parameters (see section 2.2); it may also
eliminate any header field not explicitly treated (the subject field
and those listed in 2.1).  This, combined with the possible invalidity
of signatures for signed body parts, can significantly reduce the
amount of data available to the user for making a determination of
whether or not a message is legitimate.  Crafting a message that
appeared to have already gone through this encoding also seems
relatively easy, making it possible for a sender to provide a message
that does not have the normal complement of data for assessment by a
user.

Given this major loss of information, I do not believe that this
document describes an approach that should be placed on the standards
track; if the working group believes this to be valuable, it should be
delivered as informational.  This seems also to be a better fit for
the loose interoperablity strategy here:

"The format of the display-name is explicitly unspecified. Anything
  which tells the user what happened is good. Anything which produces
  an email address which might belong to someone else is bad."

Minor Issues:

The document does not describe how it relates to the other two options
the working group has discussed for downgrade.  I believe it should do
so in order to provide context for the choices made here.  A review of
the mailing list shows this message:
http://www.ietf.org/mail-archive/web/ima/current/msg04539.html as
kicking off the core rationale and relationship.   Some form of this
should be included in the document, possibly along with the "no
downgrade" option.

This document does not describe how the IMAP/POP downgrade choices
here would impact SIEVE script processing; I believe this represents
an assumption on when the downgrade takes place which should be made
explicit.

Nits:

The document says:

  Given an internationalized address "Fred Foo <[email-masked]>", an
  implementation may choose to render it e.g. as these examples:

"render" is seriously overloaded in this context.  Would "encode" work
as well here?

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2012 16:23:12 -0700

Hi Arnt,

Thanks for your quick reply.  I've added the apps-discuss list to the
distribution; I forgot them on the original, though they are usually
cc'ed on appsdir reviews.

Further comments in-line.

On Mon, Apr 23, 2012 at 3:37 PM, Arnt Gulbrandsen
<[email-masked]> wrote:
> I disgree with much of this.
>
> First off, this draft concerns itself with a corner case. The entire draft
> is about what happens when two programs that cannot communicate, do.
> Considering this impairment, it's difficult for me to speak if "major loss
> of information" or "significant problems".
>
> Further, I think that some of what you describe as problems aren't problems
> with this draft, but rather with the coexistence of internationalized and
> conventional mail. If you accept that internationalized and conventional
> mail coexist, then you have to accept that there'll be problems when
> internationalized mail reaches a conventional client. The inability of
> conventional mail client to do what's needed is the very reason why EAI
> exists.
>

I certainly hope that internationalized mail to conventional mail will
be a corner case,
but I'm not sure my personal crystal ball is clear enough for me to be
certain that will be so.
I think there may be cases where one header or a few headers become
internationalized prior to others
(From, Resent-From, and Subject come to mind).  In those cases,
something like this approach
should be considered.  The question for me is:  for that case (corner
or not), is the result
sufficient to allow a user to assess the resulting message's validity?
 If not, should the document
describing this approach be considered part of the "standards track"
set of mail specifications?

The second question is trickier than the first; I think the first is
clear enough (if you allow the server
to excise large swathes of context, it's going to be hard to judge).
The second question is trickier, and it delves
pretty close to standards theory rather than being limited to this
document.  But my personal assessment
is that this document would do as much good as an informational for
those wanting a specification as it
would as a standards track document, and that keeping it off the
standards track may avoid some
development/deployment by folks seeing this as a valid alternative to
actually deploying an
internationalized system.  That's a personal opinion, and it's not
that strongly held.  I will not fall on my
sword if this goes on to the standards track.

>
> On 04/23/2012 05:57 PM, Ted Hardie wrote:
>>
>> impact on the security of the email messages.
>
>
> I disagree strongly.
>
> Signatures generally sign something that includes addresses, and addresses
> cannot be served legally as-is. This makes breaking either POP/IMAP or
> signatures a necessary consequence of having downgrade at all, so that if
> any downgrade document can ever be on the standards document, then breaking
> signatures must be acceptable.
>
> This draft breaks the signatures in more cases. For instance, it might break
> a DKIM signature that signs only Content-Disposition and neither To, From,
> Cc or Subject. But I'm not going to worry about that. It's simply not
> significant.
>

I am not sure *any* downgrade doc belongs on the standards track, if that helps
clarify my review.  I think losing security characteristics of the
sent message in order
to accomplish post-transformation delivery is a trade-off that raises
general concerns,
especially where a signature is present.

> Major?
> IMO this is a fair description: Geld the addresses you have to, preserve the
> other major stuff, drop the minor stuff.
>
> Mime parameters are near the border. If RFC 2231 were better supported I
> might lean towards doing something with them. But...
>
>
>> whether or not a message is legitimate.
>
>
> You seem to be describing a user who knows much about internationalized
> mail, who corresponds using internationalized mail, but who has no software
> that supports it. Yes, it's hard on that user ;)
>

I think I am describing a conventional user more than an internationalized email
user.  If you have an expectation that an email message should contain
certain things
(or your user agent checks for validity by looking for specific
things), this won't even present
you nonsense in some places you are expecting sense.  It simply cuts
the data.  How can
the user or her delegated software assess that?

> My general answer is that the best way to help that user is to spend less
> time on downgrade support and more time on getting EAI support in more
> software.
>

On this, we agree.

>> Crafting a message that
> The assessment data is generally ASCII now, why would that change?
>

If I craft a message without any of the headers that this allows me to
excise and with
.invalid-ed in From and Re-sent From, how can the user or the user
agent distinguish
that from the action of the server here?

>
>> Given this major loss of information,
>
>
> It's difficult to predict the future, but from the mail I've seen the loss
> is unlikely to be major.
>
>
> I haven't added anything like this, because I'm not sure which document
> should contain it.
>
> I'll happily supply text.
>

Thanks.  A pointer to text in another document would be equally valid.

> It isn't?
> Would you be happy if the document specifies explicitly that the stored form
> has to be the original message, not the synthesised form?

Yes, I think that would be a useful addition.

regards,

Ted Hardie

>
>
>> Nits:
>>
>> The document says:
>>
>>    Given an internationalized address "Fred Foo<[email-masked]>", an
> IMO encode suffers more from overload. But all of the candidate verbs suffer
> to some degree.
>
> Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 24 Apr 2012 19:34:21 +0200

> cc'ed on appsdir reviews.

I wondered about that. "Shouldn't there be a Cc to that mailing list 
that always refuses my reply?"

> but I'm not sure my personal crystal ball is clear enough for me to be

My path to enlightenment was:

Assume that you have EAI and I not. Then your first mail would have been 
the last in this thread. At that point I have two options: Accept not 
replying (in which case the message count stays at one) or upgrade my 
client (which is bothering me to do so anyway, as chance will have it).

How many times will I accept not being able to reply before I either 
shout at you (on the phone) to stop being so $#@$!#@$ internationalized 
or upgrade my own client? Few enough, I guess, that it remains an odd case.

(I'm told this how Microsoft makes people upgrade to new versions of Word.)

> I am not sure*any*  downgrade doc belongs on the standards track, if that helps

Yeah. You could say that's why it was do easy for John to goad me into 
writing this document. I feel that the transition period (when most 
users have only conventional clients but some users send some 
internationalized mail) is bad and ugly and should be abbreviated at 
almost any cost, and therefore implementers should get to work 
implementing EAI proper rather than downgrade.

Maybe -simpledowngrade should mention how wondrously easy it is for an 
IMAP client to learn to read internationalized email? (Sending may be a 
little tricky, but reading really is simple.)

>> >  that supports it. Yes, it's hard on that user;)
>> >

How can you assess the validity of an email message which uses new 
syntax? Syntax you don't understand?

For an IMAP client willing to learn the new syntax, the answer is easy. 
Send one ENABLE command (in IMAP) and learn to accept UTF-8 in all the 
places where you only accepted ASCII until now. For someone not willing 
to learn the new syntax, I don't think the question can have any very 
good answer.

> that from the action of the server here?

Why is that task worth supporting?

I can think of an easy way to support it within simpledowngrade (a new 
FETCH item). But issuing the ENABLE command and doing the analysis based 
on the pristine message is just as easy.

> Thanks.  A pointer to text in another document would be equally valid.

My gut feeling is that we'll end up with an overview document of some 
sort which links to both downgrade documents, and that that document is 
the right place. But I confess I haven't tried to work out what that 
means in concrete terms.

> Yes, I think that would be a useful addition.

OK.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 24 Apr 2012 21:03:54 +0200

Hi,

I went for a walk and pondered Ted's reading of the simpledowngrade 
document.

I wonder if it might not be a good idea to have an informational RFC 
entitled "The transition to internationalized mail", "Implementation 
recommendations for internationalized mail" or similar.

A page or a little more for each of a) MUAs as readers, b) as writers, 
c) IMAP servers, d) POP servers, e) MSAs and f) MTAs. A little bit of 
overview text, some examples, pointers to the relevant specifications 
for each. Not a single MUST or SHOULD, more than a bit of handwaving and 
general prose.

I'm willing to write it. Unless it exists and I've missed it, which 
would please me greatly. In that case I'll want to refer to it from 
simpledowngrade.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Apr 2012 13:40:39 -0700 (PDT)

> that does not have the normal complement of data for assessment by a

20 years ago MIME defined multipart/alternative, a mechanism by which different
users see different variations of the content of a message. This
opened the door wide to abuses where the variations actually say different
things.

This mechanism has proved to be incredibly popular - I personally recieve at
least a dozen messages employing multipart/alternative a day, mostly from
mailing lists with very large distributions. In a significant number of cases
the content of the alternatives is, shall we say, less than equivalent,
including lots of cases where there is simply no justification for the lack of
equivalence. But this is the result of carelessess, not abuse. (In fact I don't
believe I've ever heard of a case of outright abuse. If anyone has heard of one
I'd like to know about it.)

The IETF has had at least two working groups specifically focused on gatewaying
messages into restricted enviroments (FAX and voicemail), where the original
fidelity of many messages cannot possibly be maintained. An assortment of
standards-track documents have emerged from the these groups, including ones
defining fairly general mechanisms that give the sender (not the recipient)
some measure of control over various sorts of message alterations that include,
but are not limited to, excision of some content.

And then there's the practical, everyday reality, where message parts are
routinely converted from one form to another or simply removed, sometimes for
good reason and sometimes not. Sometimes annotations are used to note that such
operations have been performed, but a lot of times there is no indication that
such actions were performed anywhere in the message. (And it is highly
debatable given current client behavior whether or not adding a nonstandard
header actually constitutes any sort of real notification.)

The milter interface is an interesting manifestation of this. It provides for
wholesale modification of message content, and the popular MIMEdefang software
exploits this capability to provide all sorts of message modification
facilities.

In the specific case of MIME parameters, due to the presence of actively
exploited buffer overrun bugs in certain clients, it sometimes has been
necessary to length-limit or even remove certain parameters, including ones
that could be useful in determining message authenticity.

More generally, the business world seems to operate on the basis of documents
stored in various proprietary formats that are continually evolving and
changing, to the point where even if everyone uses the same program high
fidelity reproduction is often not achieved, and this often includes parts of
said documents being visible to some people and not others. And with different
programs... let me just say I have four different programs I switch between in
order to view the content of various documents because none of them work in all
cases.

So, while I am bit sympathetic (but not a whole lot) to the argument that we
shouldn't make an extremely bad situation a very tiny bit worse as part of a
transition plan, might I respectfully suggest that if this issue was important
to you, you're raising it about 25 years too late, and that the proverbial
horse left the barn long ago and we're now dealing with its 5th generation
offspring?

Oh, and as for the risk associated with being able to craft a nefarious message
that has undergone this transition, in order for that to stand any chance of
working you'd have to know that:

(a) The recipient has an EAI-enabled mailbox.
(b) The recipient uses a non-EAI client on that mailbox.
(c) The recipient never uses an EAI client on that mailbox.

It seems very likely that if you know all this, you know more than enough to be
able to fake things without resorting to this technique, especially given how
easily spoofable email in general is. Put differently, this is so far down the
branches of the attack tree we're talking about twigs where there are study
branches galore to stand on.

> delivered as informational.

Frankly, I have little use for any of these schemes. My take is that the
combination of EAI with a non-EAI-capable client is sufficiently toxic - and
more importantly, so likely to be a major support call generator - that the
approach I strongly prefer is to simply not allow a non-EAI client to access an
EAI mailbox. In such a scenario the only place I see a use for downgrading is
if an upgrade was done in error and has to be reversed.

That said, given the present day reality of how email works, I also think the
security issues you're talking about here a very small beer both compared with
the security issues email has irrespective of EAI and to the other operational
problems downgrading is going to cause.

>  This seems also to be a better fit for

>   an email address which might belong to someone else is bad."

For better or worse, current mail access protocols provide no means of issuing
such a warning in a reliable fashion. And while adding the capability to do
this in a reliable fashion might be an interesting discussion, we of course
cannot have deployment of EAI depend on a mechanism that hasn't even been
defined, let alone universally deployed.

> ...

> an assumption on when the downgrade takes place which should be made

I'm not sure I see the issue. Unless the scope has been expanded at some point,
downgrading is intended to happen only when a non-EAI client accesses a message
in an EAI mailbox. (This, BTW, would provide a means by which fake messages
crafted to look like downgraded messages could be detected and dealt with,
assuming you think it is worth it, which I don't.)

Sieve processing is supposed to occur at  or around the time of final delivery,
so it happens before any of this stuff comes into play. Of course there is some
Sieve usage after message download, but in that case it happens after
downgrading.

It may be possible, depending on what client or clients are used, that a
mixture of downgraded and non-downgraded messages could be processed. Indeed,
it's entirely possible for both forms of the same message to be processed with
different results. But this is again small beer compared to the confusion this
will cause independent of any Sieve usage, and is why I think the intended use
of these downgrade mechanisms is actually a bad idea.

				Ned

P.S. Please note that I have not objected to these documents going on the
standards track. I understand the use-case for them even if I don't think it's
a good idea.

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2012 04:04:31 -0000

>recommendations for internationalized mail" or similar.

It's not a bad idea.  It would be helpful if it could give some of the
motivations for NOT providing more complex backward compatibility and
downgrade options, basically that they all turned out to add more
problems than they solved, and that the goal is to encourage people
to move to an all-EAI environment.

R's,
John