How to make e-mail encrypted for everyone

To make sure I fully understand the proposal, it is to:

1. Generate public/private key pairs for all mailboxes at a given domain 2. Publish the public key in a DNS record at the mailbox domain 3. Encrypt message bodies with that public key in the MUA at send-time

A few comments (assuming I understand correctly):

First, this sounds a lot like SMIMEA (https://tools.ietf.org/html/draft-ietf-dane-smime-00) or OPENPGPKEY (https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-02) DNS records.

One requirement in this approach (not mentioned in the linked article) is that this only makes sense if you use DNSSEC. If you don't use DNSSEC, all the threats that apply to opportunistic STARTTLS apply.

There are pros and cons of DNSSEC, and various deployment issues, but in general SMIMEA and OPENPGPKEY are both basically workable. (Another option, widely discussed but as far as I know not specified in a formal protocol, is to use HTTPS and webfinger with CA-signed certs for key discovery.)

Second, I think there are a number of smaller errors in this blog post.

1. The primary issue with STARTTLS is not the two listed here (lack of encryption at rest, downgrades on "the whole chain") but rather the fact that it is opportunistic and enforces no certificate authentication. So active MITM attacks (DNS injection or stripping, to name a few) work. But they work on the proposed scheme as well, since nowhere is it specified that we must use DNSSEC!

2. I don't understand how server-side key management avoids the encrypted-at-rest issue, since the keys are stored on the server!

3. The focus on client-to-server (i.e. MUA to MTA) connections seems spurious to me, since (as others noted here) the vast majority of users use a handful of MUAs that do enforce SSL (mainly web browsers, Apple Mail, and mobile mail clients like iOS Mail or Android's Mail app). The real issue is server-to-server (i.e. MTA-to-MTA) connections.

4. Encrypting message bodies leaks header metadata. Given the fact that this proposal seems to primarily suggest server-side key management, it's not really "end-to-end" encryption anyway, so it sacrifices metadata leaks to gain...nothing. Doing transport-layer encryption between servers is effectively a better option.

So tl;dr:

In broad strokes, the proposal makes sense and reads like a slightly less-detailed version of a couple of existing IETF proposals. But as with everything, the devil is in the details.

Hope that makes sense.

What you're missing is the proposal to have the email provider generate public key/private key pairs and somehow communicate that detail to the email client. (Presumably via some IMAP or POP query?). The current IETF drafts have no provision for how to communicate public keys and private keys to the email provider.

I'll also point out that S/MIME 3.1 lets you encrypt message headers by including an entire message/rfc822 inside an encrypted section. I don't think any email client actually supports doing anything reasonable about that.

Exactly, but the author of the post didn't realize that.

Instead

> Some may frown reading that I suggest leaving the private key in the hands of your e-mail provider. I agree that this means you lose some privacy to your e-mail provider.

It completely defeats the purpose of encrypting the message. If you are sending encrypted email from (example) your Gmail account to another Gmail account, the message must be totally protected from Google to read, index, possibly giving it to any third party. So, no encryption and decryption using sw made by Google which could be changed in every moment to spy on you.

I just don't see how encryption could work in a web mail. Only client side will do.

Probably many more than you expect.

I was certainly surprised by how many users there were when I took over responsibility for such mail systems five years or so ago.

In our case the answer is "thousands" -- and we're relatively small.