> 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?
I manage e-mail servers used by "smaller" government users (individual agencies/offices, municipalities, and counties), schools, businesses and individuals -- those who are typically using a "real" mail client (e.g. Outlook) over web-based mail (although we offer that as well).
I haven't ran any type of extensive usage statistics but from what I see daily plain-text POP3 (i.e. 110/TCP) is overwhelmingly more popular than anything else. STARTTLS (with both POP3 and IMAP4) is a bit behind that, followed by {POP3,IMAP4}-over-TLS (i.e. 99{5,3}/TCP).
This is probably due to a mostly stable user base that doesn't reconfigure or set up new mail clients often. As new mail clients are installed / configured, they typically use "native TLS" (not STARTTLS) but I think this is likely because of the autoconfig/autodiscovery that most mail clients (especially mobile) support nowadays.
We will hopefully be completely doing away with plain-text mail "soon" but it will require a LOT of reconfiguring of mail clients.
A worrying number of small companies who hire "an IT guy" who will promptly install an unpatched old version of Exchange Server and only turn on POP3. (Yes, paying for Exchange and not having ActiveSync.)
This is why the best thing for most small companies is to just use hosted Google or Microsoft mail.
I don't have any stats, but I imagine lots of users still connect over unencrypted ports directly to their ISP. We have to remember that most users are not like the HackerNews demographics. If you have stats that points to this conclusion being wrong I'm happy to change my mind.
Note that this is MX-MX routing of emails between email providers, which sort have has to allow plaintext in practice.
The question of user-level IMAP/POP/SMTP access is different, but I'd expect somewhere in the region of 95+%. Note that the IMAP specification prohibits authentication that sends passwords in the plaintext [1] (although I don't know if the various IMAP servers permit AUTHENTICATE PLAIN before STARTTLS--checking, Outlook doesn't, and the other servers I had access to aren't open on 143 anyways), which means IMAP in practice requires SSL.
[1] The alternative is to use schemes like CRAM-MD5 or SCRAM-SHA-1 which don't send the password in plaintext, although these have become quite rare in practice.
Fortunately most ISPs and mail providers have disabled unencrypted logins. And many mail clients give really scary warnings if you try to use unencrypted imap or pop3.
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.
> there's no "middleman" unless you are using an e-mail forwarding service
Each time an e-mail passes through an e-mail service that service is required to add a "Received" header to the e-mail. So you can easily check out of your real e-mails to see if you are using any middleman or not. The first e-mail I opened looks like this:
Received: from exdb06.ug.kth.se (192.168.32.116) by exdb02.ug.kth.se
Received: from mx5.kth.se (130.237.32.10) by exdb06.ug.kth.se (192.168.32.116)
Received: from mx5.kth.se (localhost [127.0.0.1])
Received: from mx5.kth.se ([127.0.0.1])
Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24])
Received: from relay.mailchannels.net (localhost [127.0.0.1])
Received: from uscentral412.accountservergroup.com (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41])
Received: from uscentral412.accountservergroup.com (uscentral412.accountservergroup.com [10.102.194.57])
Received: from friendly by uscentral412.accountservergroup.com with local (Exim 4.87)
Please see the other comments to find lots of real world examples of people sending unencrypted e-mail via their ISP without knowing about it. These are the audience for these kinds of ideas, not people that already have PGP installed. I don't see where you got that idea from?
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.
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.
I can see huge problems i educating people to look after their private keys. Imagine how many people would lose their keys and their entire mail archive is unreadable.
Just this week I had TWO colleagues separately losing their respektive 2FA for github. And they both work in IT, one had saved the recovery codes, but couldn't make them work, the other not.
In a time of cloud convenience, people are actually less and less inclined to understand the concept of public key crypto and the importance of backing up private keys.
Even if you trust say, apple's icloud keychain (which isn't necessarily a great idea), it still requires access to a trusted device, and it's locked in.
So I think the biggest nut to crack is a unified cloud based private key backup that seamlessly integrates with everything from web applications to every OS and then get Microsoft/Apple/Google on board to support it every where.
iCloud Keychain can still be recovered without any trusted device. They have some kind of escrow system for recovery. It was mentioned in the talk given recently by one of their security people.
I don't agree with this. Compare to how your bank has access to your bank statement. In an ideal world that wouldn't be the case, only you would have access to it, but making sure that you use HTTPS when accessing your banks website.
So: It's not perfect, but it's better than what we have today.
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.
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.
I haven't seen them in a room together but they each have something available. Making it Chrome/Gmail extension, Firefox plugin, and Thunderbird Enigmail interoperable may go a long way. Still UI issues and apathy that will hurt uptake. To start with.
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).
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.
In p≡p there's both, automatic key management and a KeySync protocol (yet being tested, not activated already) to sync private key material across the devices you want to read the same messages on.
As you say correctly, of course you've to take care: as a common denominator an id is used, in case of e-mail a certain mail address, whose e-mail channel for communicaion functions as the key exchange channel, too (meaning the devices send themselves messages ("beacons"), which are considered as technical messages by the p≡p engine and thus never shown to the user as such).
=> If you fear to have a cell phone hacked or lost, it's better to not put that in a device group. Also you can seperate business from private accounts or have different accounts and on top of that aliases for whatever purposes, referencing the same id (mail address). In short: you can have (like mostly today) no device group at all or just different device groups meeting your needs and "paranoia levels" (based on the trust you put in your devices).
The devices agree on a device group key pair, being the master key pair, still they sync all devices' private keys for that specific id, such that you can read all of your messages received on all of your devices (even if there were changing pubkeys in between used for encryption, because of your different devices, which were not yet synced in the past).
If a device is lost or stolen, that has to be manually signalized by one of the other devices in the device group and then the devices have to agree on an new device group key pair to encrypt their future communications (we're talking of PGP encryption here, so no forwad secrecy).
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.
not death of all email - i think lima talks about that it's too late for per-default end-to-end encrypted email. encrypted transport to/from the server is relatively easy, but client-to-client? email wasn't really built that way and now the barrier of entry for broad adoption is too high.
> 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.
I agree this would be a good thing. Problem is that then the access of the public key needs to be encrypted too, which in turn means you need to make sure you use HTTPS. I think this would be a good thing, but I'm hesitant to make it an requirement.
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:
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
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.
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.
I wasn't aware of that, but of course the destination is still leaked via RCPT. If the server is going to provision keys (and presumably thus escrow them), this is strictly less private than using server-to-server encryption.
Um, how many users use native clients on unencrypted ports as opposed to https based web-clients or TLS?