Subject: Re: E-Mail Protocol Security Measurements

From: John C Klensin <[email-masked]>
Date: Sun, 02 Aug 2015 12:07:58 -0400

--On Monday, July 27, 2015 15:17 +0200 Aaron Zauner
<[email-masked]> wrote:

> Hi,
> 
> UTA chairs recommended sending a mail about this to the UTA
> and IETF lists. We're currently analyzing our datasets -- so
> more/detailed data will become available shortly.
> 
> Over the past couple of months we've been collecting SMTP,
> IMAP and POP (implicit TLS, STARTTLS) security measurements
> (primarily relating to TLS, X.509 Certs and offered protocol
> extensions). I've given a short talk at IETF93 in SAAG on the
> topic, the slides can be found over here:
> https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf
>...
> We don't yet have a publication ready and our data sets are
> currently not public, but will be in the foreseeable future.
> However we're happy to provide details if any of you have
> questions.

Hi.  I'm very much in favor of this work being done, results
being published, and discussions being used to improve things.
At the same time, I want to express a concern and hope it is
reflected in any documents or recommendations.   

We know that there is still a lot of multiple-hop/
multiple-MTA-in-path email around, especially if one includes
paths between the message-creation process and the submission
server and between the delivery server, mailstore, and user/MUA
that may involve dubious trust relationships or weak user
authentication.  Unless things have changed significantly in
recent years, in most environments and for most attackers other
than governments engaged in pervasive surveillance, attacks on
servers hosting MTAs or mailstores are easier and more likely to
be productive than attacks on message transport between MTAs.

Whether one believes in OpenPGP, S/MIME, or something else, we
know that the only really strong protection for message content
that is relatively immune from compromised relays or mailstores
(as well as from weak links in the transmission chain) involves
encryption at the source and under the direct control of the
sending user and decryption at the destination under the direct
control of the receiving user.    We also know that those
techniques are little-used and that are a lot of theories as to
why not.  That low level of use may be, and probably is, a good
reason for a concentrated effort on link encryption.   However,
we shouldn't make arguments for good-quality link encryption
that have the effect of convincing people (even the fairly
naive) that it makes either end-to-end content encryption or
relay server hardening unnecessary or undesirable.  And we
should recognize that a message-originating site that transmits
only (or only when the site identifies it as relevant) signed
and encrypted messages but that chooses to not support the
latest and best in link encryption is thereby inherently less
secure or a less appropriate correspondent than one that uses
link encryption alone.

As I said, I favor this work, but there has been too much
history in computer science and networking of coming up with
easy solutions that make people feel good about "doing
something" but that don't actually address the critical-path
problems.  I'm not suggesting this is one of those cases, but we
should pay attention and be very careful that improvements in
relatively unimportant or low-risk areas don't drive out more
effective or comprehensive solutions.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Aug 2015 19:48:24 +0100

I just want to disagree with what I think is a false dichotomy
that you presented.

On 02/08/15 17:07, John C Klensin wrote:
>  However,
> relay server hardening unnecessary or undesirable. 

We should make arguments for use of TLS in mail. Deploying
that provides real security and privacy benefits. And there
are real improvements happening today in terms of deploying
TLS in mail. I say encourage that as much as possible.

For the niches where PGP or SMIME is usable, we should of
course also promote use of those technologies *in addition
to* TLS for securing mail transport. That is very much "in
addition to" and not "versus."

IOW, we should promote use of mail transport security
everywhere and of PGP and SMIME anywhere those can be used.

We separately need to work on providing much more widely
usable end-to-end security for email. Neither PGP nor SMIME
have worked well enough to get widely deployed and we
should recognise that fact. And one of today's most common
kinds of MUA (web mail) was never considered in the design
of PGP or SMIME, and the need to support such MUAs breaks
or almost breaks any e2e security one gets with our current
standard e2e email security protocols.

We cannot therefore credibly argue for widespread deployment
of end-to-end security for email today. I wish that were not
the case, but it is the case.

So "don't promote TLS in case that slows deployment of PGP or
SMIME" is not a good argument - the dichotomy is false as the
wide deployment of PGP or SMIME providing e2e security is not
possible.

We have a (sadly quiescent) mailing list [1] for discussion
of new end-to-end email security. I'd love to see discussions
there as to how to improve the e2e situation.

But I would if "fix e2e email security" was ever seen as a
precursor to better deployment of mail transport security. That'd
be entirely counter-productive.

While it is sometimes understandable that folks make the error
of arguing for the perfect and that being the enemy of the good,
I really don't want to see us argue for the unusable as the
enemy of the good.

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/endymail

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 2 Aug 2015 19:37:11 +0000

> TLS in mail. I say encourage that as much as possible.

I might add that without totally redesigning SMTP, both SMIME and
OPENPGP leak the message envelope and headers in the clear unless
hop-by-hop TLS is employed.  Yes, the intermediate nodes also need
to not be compromised for this to be maximally effective.

I don't view SMTP transport security as a technology that aims to
guarantee to protect the end-to-end confidentiality of any particular
message flow, there are indeed too many moving parts to make strong
end-to-end security claims.

Rather, SMTP transport security substantially increases the *average*
security of mail traffic.  It becomes much more difficult to collect
it in bulk.  (Yes compromising a relay at Gmail, Yahoo, outlook.com,
would be a major coup).

So think of SMTP transport security as a form of vaccination, it
won't protect every individual, but is beneficial to the community
as a whole.  [ We should not get too carried away with the analogy. ]

Note that even if scalable and secure key management were available
for end-to-end email today, there are still major barriers to
effective use of the technology, because encrypted email is a pain
to use even with key management solved.  I am willing to own up to
not wanting all but a tiny fraction of my email encrypted end-to-end:

    * Encrypted email is difficult to search.

    * It is difficult to rotate one's keys while retaining access
      to past email.

    * The signatures of long ago received messages signed with
      (somewhat less) long-ago expired keys are poorly handled by
      MUAs.

To get closer to usable end-to-end secure email, we'd need to move
back to a POP-style mailbox access model:

    * E2E mail is delivered to POP-style servers, which hold
      mail only long enough for one of the user's MUAs to
      retrieve it.

    * Instead of IMAP, the MUA would have access to a scalable
      (often cloud based, to support mobile devices) encrypted file
      system, with search performed by the device (more bandwidth
      required than server-side search, but that's the price one pays).

    * Email would be decrypted on download from the POP server,
      all signatures checked, ... and the resulting message and
      metadata (plus search index updates) would be stored in the
      encrypted filesystem.

    An alternative is for each device to cache all the user's email,
    on a local encrypted store, with a local index, and maybe even
    a local IMAP server, to support legacy MUAs.  This would require
    considerably expanded storage on mobile phones and the like.

This (or a functionally equivalent) change in the architecture of
email access and storage is unlikely to happen any time soon.  In
the mean time, end-to-end encrypted email will remain a niche
technology.

If everyone started sending me encrypted email, the key I'd publish
would be stored on my MTA, and email would be decrypted before it
is stored in my mailbox.  Keys that only I know would be given
individually to just a small number of people.  Similarly my signature
key for random recipients would be applied by the MSA, keeping the
bulk of my email in cleartext on the IMAP server.

I am not at present (or likely any time soon to be) sufficiently
motivated to put up with the stupendous inconvenience of a large
mailstore in which all the mail is encrypted with SMIME or PGP.

If anyone really wants Johnny to encrypt, then the usability of
one's archive of previously received encrypted email would have to
improve dramatically.  The necessary investment in mailstore and
MUA functionality while most user's email is "free" and funded by
advertising seems unlikely.

-- 
	Viktor.