On Sun, Aug 02, 2015 at 07:48:24PM +0100, Stephen Farrell wrote:
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.
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.