Subject: [EAI] Review of draft-ietf-eai-simpledowngrade-03

From: "John Levine" <[email-masked]>
Date: 30 Apr 2012 02:55:40 -0000

The goal of this draft is to pare back the downgrade process in IMAP
and POP servers to the minimum required to create a message that can
be presented to a non-EAI mail client, and more or less looks like
the EAI original.  It presents a simple set of downgrades that will
give the recipient a reasonable idea of what the message said, and
will still allow replies to non-EAI addresses in the header, while
being a lot less work than prior proposals.

My only suggestion is that in section 1, it'd be worth reminding
people that since a non-EAI client can't send mail to an EAI address,
there are no modifications to an EAI message that would allow a
pre-EAI client to interoperate with EAI mail. That means a decision
about what to do with downgraded message elements is aesthetic, not
technical.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Apr 2012 11:37:59 -0400

> It presents a simple set of downgrades that will

Yes, and I think it's very useful for those reasons:
1. give the recipient a reasonable idea of what the message said
2. a lot less work

> about what to do with downgraded message elements is aesthetic, not

That aside, the reviews that are coming in are focusing on security issues:
- What implications do either of the pop/imap downgrade proposals have
on client processing of any sorts of signatures?
- What implications are there on any Sieve processing in the client? [1]
- What possible attacks can take advantage of this sort of thing to
fool people during an expected transition period?

I'm not sure how we should respond to these.  We seem to have
consensus that this sort of processing is useful to help users through
a transition.  My sense is that we don't think the security concerns
are serious.

Barry

[1] While Sieve processing is normally done in the MDA, there are
clients that do Sieve processing.

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 30 Apr 2012 17:56:45 +0200 (CEST)

> a transition.  My sense is that we don't think the security concerns

well... I'm biased, as I'm one of the reviwers who commented about 
security issues :-)

but... I recently held a security firedrill test: I sent out something 
whch was clearly a phising message to collect credentials, a message which 
did break all security mechanisms, signatures, etc... and this message 
(BTW, a pure ASCII message!) was sent not to end users... it was sent to 
e-mail administrators, and to local security administrators within my 
constituency (the Italian Academic and Research Network) at first, and 
then sent to other research networks around the World... just localized in 
the local language:

  - 36%  (yes... 1 out of 3) responded submitting credentials (the real
    ones).

I'm not only biased... I'm seriously concerned! :-)

all the best!

PS: maybe users are less simple-minded than administators... who knows!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 30 Apr 2012 18:12:44 +0200

I believe that the security problems are intractable. For instance, we could preserve signature verifiability if and only if no eai addresses are signed or used during verification. I really don't want to write either code or a spec for such a special case.

Put simply: How would you verify a signature without knowing the syntax used in the sender's address?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 30 Apr 2012 18:43:59 +0200

Uh.

If lots of EAI messages end up being generated without any EAI
addresses, and lots of conventional clients remain in use for a long
time, then I'm wrong about the signatures. Happily, in that case server
could legally add more fidelity to enable signature verification: There
is no MUST NOT in the simpledowngrade draft.

Arnt

---

From: [email-masked]
Date: Mon, 30 Apr 2012 09:36:20 -0700 (PDT)

> 1. give the recipient a reasonable idea of what the message said

Whether or not it's a good idea for end users can be argued either way, but my
perspective is different: I look at this from a service provider's viewpoint.
And from that viewpoint downgrading looks likely to be a massive support call
generator. As such, I think it's unlikely that most providers will ever deploy
such a mechanism. I think providers are more likely to use an approach where
mailboxes are transitioned on user request and once a transition is done that
mailbox cannot be accessed by a non-EAI client.

This doesn't mean that downgrading is useless - it will be needed if a mailbox
is transitioned in error and has to be downgraded to non-EAI. But that case
raises far fewer issues than mixed client access does.

> That aside, the reviews that are coming in are focusing on security issues:

Since my previous rant on this topic appears to have been ignored, I'll again
point out that this concern is fundamentally 20 years too late and many
trillions of messages short.

> on client processing of any sorts of signatures?

OK, if we're really sure we want to explore this rathole, then I'm going to
insist that we go all the way to the bottom.

DKIM first. DKIM is of course going to fail, but since the focus of DKIM isn't
to be an end-to-end mechanism (various attempts to promote it as such
notwithstanding), I'd have to say this is not a big concern.

Multipart/signed is a different problem. I'll first note that the
multipart/signed specification says signed content is constrained to be 7bit 
(RFC 1847 section 2.1.), so that's an issue for EAI irrespective of any of this
downgrade business. So perhaps we need to define an additional container for
EAI content that will fit inside a multipart/signed. Application/global? (We
could also reuse message/global, but I don't like that because the semantics
aren't correct.)

Note that multipart/global-signed is NOT an option. There's lots of
special-case handling of multipart/signed out there that cannot be easily
upgraded.

But let's assume that the right thing to do is to remove the restriction on
multipart/signed. (I think that's a terrible idea, but let's suppose.) Well,
the solution then is to wrap the multipart/signed on the outside if you want to
preserve the signature.

Either way solving the problem is effectively outside the scope of the
downgrading specification.

Next up are signature schemes that employ their own private media type. Since
such schemes by definition cannot carry objects with message semantics in a
standardized way, they aren't going to be affected by either EAI or EAI
downgrading.

And as for the various signature schemes that are embedded in text parts,
they're essentially the same as using a private media type. Yes, the content
can end up multiply encoded, but that's already the case and presumably the
various agents out there can deal with it.

So the bottom line is that if signatures are seen to be an issue, they're an
issue with EAI in general, not specifically with downgrading. And if you want
to solve it, any real solution is almost certainly going to deal with the
downgrading problem.
 
> - What implications are there on any Sieve processing in the client? [1]

Since a non-EAI-capable client is never going to have seen or have had to deal
with EAI messages, I'm not sure I see a big issue here - and most of the
smaller issues that this raises are also created by the use of constructs like
message/global, which have to be dealt with no matter what.

> fool people during an expected transition period?

Wrong question. The correct question is what additional attacks does this make
possible given that all email headers are trivially spoofable (which makes it
possible to send different versions of the same message to different people
while making it look like they got the same thing) and given the existence of
multipart/alternative. And it should be up to the complainers to come up with
serious examples of this, because otherwise you're in effect demanding proof of
a negative, which is bogus.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 30 Apr 2012 16:50:18 -0400

> mailbox cannot be accessed by a non-EAI client.

The issue that I believe caused us to stick our foot into this tarpit is 
that a system with mixed EAI and non-EAI users is likely to get EAI 
messages for non-EAI users.  None of the options are great, reject them as 
they come in, pretend they don't exist for POP and IMAP users, or 
downgrade.  Rejecting will lose mail that could be delivered if the user 
notifies the service to upgrade between the time the message arrives and 
the next time he reads his mail.  Pretending the mail isn't there has 
correctly been described as a cruel joke.

So I think that you can make a reasonable case that downgrade is the least 
bad of the three, but I also do not want to require or encourage an 
elaborate transition scheme.

The basic answer to any comment along the lines of "this sucks" is "you're 
right, and the way to unsuck it is to give the user an EAI mail client."

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "John R Levine" <[email-masked]>
Date: 30 Apr 2012 17:43:09 -0400

> on client processing of any sorts of signatures?

It probably won't work.  Users who care should find an EAI mail client.

> - What implications are there on any Sieve processing in the client?

It probably won't work.  Users who care should find an EAI mail client.

> fool people during an expected transition period?

Given the range of technically trivial attacks, e.g., Claudio's simple 
phish which fooled 1/3 of the admins he sent it to, why would anyone waste 
their time on something specific to the 0.1% of people who are reading 
downgraded EAI messages?  Users who care shound find an EAI mail client.

Regards,

---

From: [email-masked]
Date: Mon, 30 Apr 2012 14:50:28 -0700 (PDT)

> elaborate transition scheme.

Again, it depends on your perspective. "Least bad" for the user is often not
the same as "least bad" for the service provider. And the reality is service
providers tend rank lower costs above user convenience.

> right, and the way to unsuck it is to give the user an EAI mail client."

Agreed. And what this means in the service provider space is that they'll have
an EAI-capable webmail solution before they would even consider offering EAI an
EAI-capable mail store. But if anything that moves things away from
downgrading, because their response to user complaints about the mailbox being
inaccessible is going to be, "Why not use our webmail?".

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 30 Apr 2012 18:03:11 -0400

> providers tend rank lower costs above user convenience.

Depends on the service provider.  Random giant mail host, sure. 
University IT department who have to do whatever the faculty wants, no 
matter how ill-informed, maybe not.

I agree that a lot of places will do what you said, and roll out an entire 
EAI product at once, but if you offer POP and IMAP to people who aren't 
your employees, people will use whatever crud MUAs they want.

Regards,

---

From: [email-masked]
Date: Mon, 30 Apr 2012 14:59:39 -0700 (PDT)

>   - 36%  (yes... 1 out of 3) responded submitting credentials (the real

AFAICT this shows that signatures either aren't being validated or that the
results of those validations are being ignored in a significant number of
cases.

Either way the implications for EAI downgrading are ... what, exactly? If
signatures really don't matter, why aren't the folks concerned about security
focusing on that issue, instead of worrying about EAI downgrading, which in the
context of email signatures is demonstrably a nonissue?

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 1 May 2012 00:26:09 +0200 (CEST)

> results of those validations are being ignored in a significant number of

likely both of the above. And people just still do not care, or just have 
a wrongly configured MUA and security system, and that's why they do not 
care (bad user experience).

> focusing on that issue,

I guess they (we) are focusing on this! The above IS the real problem, and 
it has nothing specific with EAI.

> instead of worrying about EAI downgrading, which in the context of email 
> signatures is demonstrably a nonissue?

Indeed my comments about both the "downgrading" documents are not about 
worries generated by the fact that EAI downgrading breaks security (this 
is a non issue, or a minimal issue compared to the abov general problem), 
but about the way that the "Security Considerations" sections are written.
IMHO these sections should describe correctly (and clearly) the scenarios 
which can happen when a specification is implemented. E.g. declare clearly 
the potential problems, even if they happen in 0.1% of cases.
If this is done, then I'm ok with the documents :-)

---

From: Ted Hardie <[email-masked]>
Date: Mon, 30 Apr 2012 15:57:31 -0700

> it has nothing specific with EAI.

For what it is worth, I still believe the signature issue is a small
part of a more general issue:
how do I manage user expectation of what a message should look like so
that it is considered
valid?

As a user, I have certain assumptions about what I see when I get mail
via specific MUAs (e.g.
a web client, a desktop client, etc.).  If I get a few messages that
undergo downgrade (because
my friends with non-ASCII names start using their real names in
addresses or domain names or
as targets of files like _Friend_Name_Resume.pdf), that may not push
me to upgrade all MUAs
that can reach a specific mail store.  But I get used to seeing a bit
of junk as a result, and I get
used to a few things being missing that used to be there.

Then I start getting messages from other folks that has a bit more
junk in it, but it looks like
the original junk.  How can I tell that this junk is as benign as the
other junk?  How about if it is
missing more than the original crop missed, but otherwise looks
similar?  How can I tell whether
what's missing is the result of downgrade, elision at the source, or
something else? How can a naive
user?  The signature piece is a piece of this (how do I react when
something tells me the signature
is "broken"), but just a tiny piece of the overall assessment of
validity (or "normalcy", maybe?).

If people didn't make security judgements based on perceived
"validity", this would be a straight
usability issue.  But they do, and downgrading (especially when it
elides data as freely as this proposal) makes
it harder.  It may be a necessary evil for a transitional period, but
I think it should be marked as such
prominently--that's why I suggested it stay off the standards track.

As I said, though, I will not fall on my sword if I'm in the rough on
this:  no appeals or even overly loud
gnashing of teeth will come from my corner.  And to reiterate the
other point I made:  I feel the same
way about pretty much all the downgrade approaches.  Whether we are
trying to route around traditional
in-path servers or UAs, it just does not work well enough to be worth it.

My two cents as an individual,

regards,

Ted

---

From: "John R Levine" <[email-masked]>
Date: 30 Apr 2012 19:04:20 -0400

> part of a more general issue: how do I manage user expectation of what a 
> message should look like so that it is considered valid?

I entirely agree.  At some point we (for a very general construction of 
we) will have to figure out how to show messages in a way that gets the 
message through that this message is real, but it's a very hard problem.

It certainly has nothing to do with EAI.

Regards,

---

From: [email-masked]
Date: Mon, 30 Apr 2012 22:56:21 -0700 (PDT)

> If this is done, then I'm ok with the documents :-)

I'm sorry, but the point you're making here completely eludes me. Barry asked
for information to help him respond regarding the effects of downgrading on
three specific things: (1) Signatures, (2) Sieve, and (3) Additional attacks
facilitated by downgrading. I responded with an analysis that basically said
the first two are demonstrably nonissues and the third is badly posed. You then
responded with a note that essentially said signatures seem to be fairly
worthless in practice. And now you appear to be saying that the real problem is
the security considerations section lacks information about certain scenarios of
concern, but I have no idea what these scenarios are.

In any case, assuming these scenarios involve some sort of trickery in regards
to what headers are or aren't displayed by different clients, I'll fall back to 
my original point that given the ease with which email headers can be forged,
coupled with the uncertainty as to what client a given user might use, does
downgrading really change the the attack surface in any significant way? I
rather think it does not.

Now, I suppose you can argue that we should describe what amount to tiny
twigs on the attack tree even when there are enormous branches that are far
more accessible, but I'm going to have to disagree. The problem with devoting
time to what are effectively nonissues is that people waste their time reading
that verbiage when there are far more important things for them to be worrying
about.

But I freely admit I may be entirely incorrect about all this because I really
have no idea what scenarios are that you're concerned about.

				Ned