How to make e-mail encrypted for everyone

> When you send an e-mail today it’s sent in plaintext. This means that when you connect to your local coffee shop’s WiFi they can intercept all e-mail that is sent through their router. This is probably not the relationship you have with your barista…

Um, how many users use native clients on unencrypted ports as opposed to https based web-clients or TLS?

As many others have pointed out - this doesn't keep the email encrypted from the providers at either end.

We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either.

And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is reliably deployed, lots of things become easier - but you still don't need encrypt partial payloads, because there's no "middleman" unless you're using a forwarding service.

And if you're using a forwarding service, who's publishing the DNS keys? This solution didn't address that at all, the forwarding service would have to decrypt the email with the key for the alias name, then re-encrypt it to the final destination. Either that or proxy the key request, which is trivially MITMable.

Upshot - this adds complexity and theater but doesn't protect against any credible attack vector.

As for the "coffee shop reads your email". Please. Basically every server who cares about security (the audience for ideas like this) already disables non-encrypted SMTP/IMAP/POP. At FastMail we only open the ports for SSL, because STARTTLS is nice, but it's MITM removable, and even if we reject login with the plaintext password, it's already been over the wire.

https://www.fastmail.com/help/technical/ssltlsstarttls.html

I'm too lazy to find one of those checklist things to paste about why this won't work, but I'm not jumping to implement it.

The goal of encryption in email boils down to preventing your email provider from being able to read the email. (If you don't want to prevent that, then your email is already encrypted from everyone else if you and your recipient uses SSL and you use major email providers that try SSL over the internet backbone). Keeping your email provider away means your email provider can't have your private key, which means you need some way to keep the key in sync between different email clients--say desktop and smartphone.

Sounds like you are talking about Identity Based Encryption (IBE)

https://en.wikipedia.org/wiki/ID-based_encryption

There are mature, commercial products which use this to address the "PKI benefits without the overhead of managing PKI" problems. Read the wikipedia page for the gory details, but essentially, you get to use someone's email address functionally as a public key (as per traditional PKI email schemes) wihtout the recipient having to, a priori, create the pub/priv keypair. They can be derived statelessly on the fly.

For one example, See Hewlett Packard Enterprise - Data Security "SecurMail" product.

Full disclosure: I work on this product.

Here is some basic background information on how it works.

https://www.voltage.com/products/email-security/hpe-securema...

There is still a "trusted 3rd party" running the key generator (a deal-breaker for some threat models of privacy) but that generator entity doesn't have to be the ISP or email provider involved at either end.

The two biggest detraction points are completely valid:

1) The need to install ANY (non-standard) software (by definition -everyone- should already be able to use it).

2) The need for users to manage their own keys.

I envision a solution to point 1 is making it a /feature/ of every OS to implement the required software for the open protocol. Prototype on BSD/Linux, get MacOS to ship slick versions of the protocol, and use THAT to club Microsoft over the head for also shipping support with Windows.

Paired with point 1, smart USB attached keys. End users should think of that as their signature and their 'mark' for signing official legal things and literally inking a document with blood.

The USB key should at least have a few lights as an indicator and a couple of buttons.

It should be easy for the user to:

* Allow it to AUTHENTICATE a provided datastream.

* Allow it to decode and provide the unlock key for a datastream back to the computer.

* Allow it to provide a signature for a datastream.

I order those in the least to most trusted operations it should perform.

It might, for a smarter device, support multiple keys or different trust levels of keys.

With the above two frameworks in place all other problems become /far/ easier to solve, and the user experience will be much better (so it'll actually /happen/).

DNS-based key discovery has already been invented twice: PKA and OPENPGPKEY. Nobody is using it. It has an obvious problem: DNS is not secure. There is DNSSEC, but it's practically undeployed on clients, therefore building on it doesn't make sense.

GPG recently added support for key discovery via HTTPS (Web Key Service, WKS). That goes in the right direction, because it takes the best deployed working authentication system - the web pki - and bootstraps from there.

Keep a close eye at the pretty Easy Privacy (p≡p) project.

It provides an engine (written in C99) and adapters for the most important environments, in order to automatize key management and message transport.

It'll be the default way to automatically encrypt e-mails in Enigmail, where most OpenPGP traffic emerges from, anyways: https://twitter.com/pEpCouncil/status/791948659378106368

But that's just a start, as p≡p wants to transfer all text-based communications anyhow into the censorship-resistant, peer-to-peer GNUnet (using OTR or Axolotl crypto).

Cf. White Paper of p≡p: https://pep.foundation/docs/pEp-whitepaper.pdf

(Wikipedia article on p≡p showing its broad approach: https://en.wikipedia.org/wiki/Pretty_Easy_privacy)

Key management also needs to get a lot simpler and there need to be best practices!

If I only have one key for everything, it's quite dangerous for the key, because it must be on all my devices. If I create a key for each device though, how do you know which key to use? And the more keys I create the more I need to remember which is for which, when to replace one, etc. Last but not least it is REALLY HARD to erase stuff from smartphone memory. So the moment you put your key there you should know that other people will get their hands on, read your decryptet emails on the phone etc. There must be a way for me to kill it without completely erasing it, or at least a best practice for how to handle that.

Altogether I don't feel like PGP is meant for the 21st century. Or I just am not not smart enough to figure out how to make it work. I always spent a lot of time on it, and wasn't able to read all my email whenever I needed.

It's too late to fix email. Neither using GPG (as the article points out) nor anything else.

Ubiquitous, opportunistic transport encryption is the best it'll get, and we're pretty close to that.

The future of secure communication isn't email, it's incompatible, centralized silos of low-latency protocols with forward secrecy. Think WhatsApp or Signal.

> You need to install software on your computer. Most e-mail providers are moving to the web, having to install a browser plugin just to send e-mail is not the experience we should strive for. I understand that this is means your e-mail provider can read your e-mail, so it won’t work for everyone. But I think most people will accept that the same way they accept that their bank can read their bank statement. If we can trade this for usability it’s still a HUGE step up for privacy.

Yea we have that, it's called STARTTLS. If the keys arent only held by the user then there really isn't any end-to-end encryption. It's just the same as SSL.

> Since we need to know who to send the e-mail to, we should encrypt everything except the recipient address.

I would argue all that should be unencrypted us the recipient domain, just like https

Here is the same idea from 2002: http://www.dwheeler.com/essays/easy-email-sec.html

It's not going to work. All the main problems must be overcome in theory and practice before it gets deployed. Here's a summary of them from Collin Robbins:

https://cybermatters.info/2012/08/13/why-has-encrypted-email...

Note: He was one of LDAP's inventors. His company Nexor deploys both encrypted mail and high-security guards regularly. That's his credentials.

I'm impressed by the ProtonMail team. Yes, they have a way to go but are making great progress. Yes, you need to trust them. Yes, it's simple enough for my grandmother to use! The mobile app works well too.

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.