[Cryptography] What ever happened to end-to-end email encryption?

Phillip Hallam-Baker phill at hallambaker.com
Sat Aug 21 10:54:41 EDT 2021


I have given much thought to this question but as Karl Marx said, the point
is to change it. Comments inline and at the end.

On Fri, Aug 20, 2021 at 8:30 PM R Perlman <radiajpc at gmail.com> wrote:

> Despite PGP and S/MIME having been designed zillions of years ago, it
> seems like end-to-end email encryption/integrity protection are not widely
> used. Which of the following is reasonably close to the truth?
>
>    - Of course they are widely used. I'm just not aware.
>
> Roughly 1-2 million accounts activated for both. Use is not negligible but
far short of the over 4 billion users of email.


>    - The usability issues were not worked out. How would a user obtain a
>    public key? How would a user get a certificate? How would a user know the
>    public key of someone they are receiving from/sending to?
>
> A real concern but the usability threshold is much harder. If you ask the
user to make any effort whatsoever, you are lost. SSL/TLS works because it
is completely transparent and zero effort on the user's part.

The Mesh automates the process of device provisioning. So configuring
Thunderbird to use S/MIME should be a one time 30 second affair. But that
is not close to being enough.


>    - It never reached critical mass…there were never enough people who
>    could receive encrypted email that it was worth trying to figure out how to
>    send it.
>
> A valid concern and this was made much worse by the VHS/Betamax format
war. And that same issue is going to limit the growth of Signal/Telegram
etc. and keep those in a significant but small community.


>
>    - Big companies do not want end-to-end encryption of email. They want
>    to have middleboxes be able to scan for phishing links and perhaps they are
>    legally required to keep records of all email sent to or from company email
>    addresses.
>
> Big companies do not want malware vectoring in. That is a slightly
different concern. SMTP is worn out at this point. Middleboxes to scan spam
are a kludge to deal with the fact that the protocol is default insecure.
DKIM does not change that very much either.

If you want to do end-to-end encryption, you have to deal with these issues
and more. End to end means something very different in the enterprise
context. If Alice sends an order to Bob by email and Bob falls under a bus,
the corporation needs to read the email because the relationship is with
them and not with Bob.

Designers have to leave the libertarian 'its all about me, only me and
nobody apart from me' behind.


>    - Even individual users need middleboxes to scan for spam and other
>    services (such as maybe warning about dangerous links)
>
> No, we have to abandon SMTP.

Mesh messaging is access controlled. So every message Alice receives from
Sue the Spammer is rejected. All that Sue can send that Alice will receive
by default is a contact request in a highly constrained format and even
that is subject to access control.

By default, I would probably allow anyone who has attended an IETF meeting
and checked in with their Mesh profile to send me mail messages. But I
wouldn't allow just anyone to interrupt me with a voice call.


>
>    - Ordinary users just aren't worried about having their email seen by
>    others, at least not enough to figure out how to get an email client that
>    can do encryption, obtain a key, etc.
>
> And never will be. Ask nothing of the user.

>
>    - Other solutions became popular, which (I think) involve a central
>    server that a sender requests a secret key from, the sender encrypts with
>    that secret key, and then the receiver needs to ask the central server for
>    the key.  I think if a big company is using such a product, it is
>    implemented in a way that lets the company see plaintext of
>    all email to/from that company's email addresses.
>
> These are expensive hacks that offer rather little actual security but
they are widely used.


>
>    - People don't really know what different forms of "encrypted email"
>    mean, so central-server-secret-key-style, vs end-to-end with user public
>    keys, vs using TLS between mail transfer agents all count as "encrypted
>    email"
>    - Something else?
>
> The whole complexity of PKI and deciding whether alice at example.com is
'Alice'.

DNS makes a lousy basis for email addresses. Users need portable email
addresses and SMTP just can't give them that. DNS names are ridiculously
expensive and part of that is irreducible because DNS is bjorked.


I think these are all fixable and will shortly be releasing code that I
think starts on the road to a fix. But an infrastructure can only deploy if
there is a deployment strategy and that means designing for deployment. The
myopic IETF approach of 'lets make the smallest change possible' limits us
to incremental changes that are too small to be worth it for the end user.

I don't see any player in the market trying to develop an open system in
this space. Signal, Telegram etc. all force you to use their service. That
isn't open, it is a proprietary system offered for free while it builds an
audience. My criteria for success:

* It has to be genuinely open, anyone can write a client, anyone can run
their own service
* User addresses (callsigns) must be portable between service providers and
incur no renewal fees and be cheap to register (less than $0.10)

* It has to span the full range of security concerns, securing data at
rest, asynchronous messaging (mail), synchronous (chat), voice, video. All
with the same callsign (I also provide contact, password catalogs and 2nd
factor authentication)

* It has to demand no additional effort on the part of the user.

* It has to fit with real world user concerns. That is 'how do I give
access to all our data on USB sticks to Fred who just joined the company',
not 'how do I prevent the FBI from effecting a warrant for the material
under any circumstance I can imagine'.

* It should be as secure as we can make it without compromising any of the
goals above.


I am just wrapping up the final pieces so the initial tool can demonstrate
provisioning keys for SSH, S/MIME and OpenPGP. Hoping to launch very soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210821/7f6cf205/attachment.htm>


More information about the cryptography mailing list