End-to-end Encrypted Email
I really liked dcposch’s blog post about achieving easy-to-use end-to-end encrypted email. This is something that I think about once and a while, so I wanted to share my own thoughts about it! (It’s worth mentioning that I’m not a security expert.)
E2E: Desirable Properties
I want to start by outlining the major properties that I think are the most important for end-to-end encrypted email (henceforth E2E) to have.
Email has had decades to gain traction. Any E2E solution that hopes for ubiquitous adoption needs to expect to play the long game: years or likely decades of slow usage growth. This means an E2E soluton needs to work well with what’s already in use today. Something that reinvents email entirely is much less likely to catch on.
This takes a few forms:
The format of email hasn’t changed much. That’s great, because there are hundreds of mail clients out there used by millions of people. Changing the fundamental format of email is highly undesirable. Adding E2E shouldn’t change how email is structured underneath the encryption.
Said differently: any new E2E system MUST be backwards compatible with current mail clients and servers. This means E2E MUST be a transparent layer on top of normal email.
dcposch suggests putting garbage in the From: and Subject: fields, and instead adding the real values in the encrypted body. This seems like the best solution: It’d be nice to just encrypt the From: and Subject: fields in-place, but many mail clients and server start truncating subjects after 78+ characters. An encrypted GPG message for just ‘hello there’ is 892.
One solution, as suggested by dcposch, is to create a new generation of “encryption aware” mail clients. These clients would have a baked-in understanding of key managements, key exchange, encrypting incoming mail, and decrypting incoming mail.
This would be great! This should definitely be one prong of the E2E effort.
However, I don’t think it’s enough on its own: it breaks backwards compatibility, breaking every existing mail client today. People aren’t going to like having to use someone else’s mail client to enjoy E2E.
dcposch has two great ideas for reusing existing mail infrastructure to obtain E2E:
Keep the To: field in plaintext, so that the email body, From:, and Subject: fields can be encrypted safely in the body, leaking nothing except the recipient.
Route emails through Tor to their destination SMTP server. This keeps the sender’s IP address hidden.
Though I think #2 should remain an optional layer, external to the core E2E: this lets users make decisions based on their own trust model. Not everyone cares about hiding their IP address, while others may prefer instead eg I2P. Not building it into core keeps the door open for future anonymizing networks that are sure to come.
Email was designed to be decentralized.
Any new E2E layer should not make email any less decentralized than it is today.
dcposch talks about having key exchange (and discovery?) that is centralized (like Signal). I don’t know exactly how Signal does this, but I think it’s worth going into more detail about what this means, and whether it could be achieved in a decentralized fashion.
Email differs from instant messaging in that retention is generally extremely important to people. I want my email to always be accessible, no matter how much surrounding technology and formats change. This is a critical property.
The only way I can see this working is if, even with E2E present, email remains in plaintext at rest. To store encrypted runs the risk of catastrophic key loss (discussed a bit more below).
Storing in plaintext also has the added benefit that all existing mail tools (parsers, generators, readers, etc) will all keep on working as they do today.
Full disk encryption is already available and in wide use today: encrypting mail at rest doesn’t really gain us anything. However, users can still use others tools (PGP) if they’re so inclined: this lets the user choose their trust model.
No Catastrophic Key Loss
Key loss can’t catastrophic! Losing my key or password needs to either be VERY HARD to do (store lots of backups around the internet), or very low-consequence (can easily establish trust with a new key to my contacts).
Idea: Intermediary E2E Mail Proxy
A user wishes to take part in this new E2E spec. Hooray! \o/ However, they have an email workflow that they’re very comfortable with, and want to keep using the same mail client on their laptop.
One solution would be a local proxy server that does the work of making the E2E work:
- install & run a little server on your local machine
- point your normal, everyday email clients at it for SMTP and IMAP (/w TLS)
When you send a regular email to it via SMTP, it does the heavy lifting:
- doing key discovery / exchange with your recipients
- wrapping it up in the encrypted format
- sending it via Tor or I2P to the recipient’s mail server
When you ask for new messages via IMAP or POP3, it does the reverse operations:
- proxies your IMAP/POP3 requests to your real mail server
- downloads the encrypted email blobs
- uses your decryption keys to decrypt it and reformat it like a regular plaintext email
- hands it to your mail client, which gets to treat it like any other email
This lets all mail software and clients of today keep working just fine, but gain E2E superpowers. The downside, of course, is setup becomes a bit more work (having to install this program and set new IMAP/SMTP addresses).
It’s important to see this as another prong in the overall E2E effort: one to complement having fully E2E-aware mail clients like the ones dcposch is suggesting, in order to make use as transparent as possible.
Getting E2E adopted universally is going to be a long battle, so it needs to work as transparently as possible, and maximize backwards compatibility!