Why we don't offer PGP

We pride ourselves on our threat-based approach to modelling security decisions, and the transparency with which we’re willing to talk about and justify our choices.

Security is important at Fastmail. Learn more about our approach to integrity, availability, and confidentiality.

Why don’t you …?

Which brings us to a very common class of questions: by customers, by potential customers, and even by people who have no intention of becoming customers but are happily evangelising their favourite idea.

These questions are of the form “Why don’t you support {thing}”, or “I would be a customer if you implemented {thing}”, or my personal favourite: “It’s 2016, I can’t believe you don’t even {thing}!”

Occasionally we write about our reasons for NOT doing something, for example we have a position on STARTTLS on top of plaintext protocols that is at odds with a lot of the rest of the world’s thinking. We don’t provide IMAP or POP access on the standard non-encrypted port. We explain in our help pages that we feel the risk of clients being fooled into sending the password in plaintext is higher when they aren’t forced to do the SSL negotiation up-front. And if the password goes across the wire in plaintext, it doesn’t matter that we won’t accept it, a passive sniffer could already have it.

So let’s talk about encrypted email and why we’re not rushing to provide solutions in the fully end-to-end encrypted space. Firstly;

Encryption on the wire is getting better

Since Facebook posted this in 2014 the amount of server-to-server traffic that’s been encrypted has grown enormously.

Google also provide a report on how much email is encrypted in transit over time.

We’ve been doing server to server transit encryption for quite a while ourselves.

And of course all client to server traffic is fully encrypted at Fastmail, we’ve been enforcing that since 2012. We provide best practices SSL encryption with perfect forward secrecy and we are very quick to remove broken algorithms and disallow insecure connections.

Traceability is getting better

With DKIM Signing which is widely deployed and which Fastmail has supported for quite a while, you can authenticate the source of an email and confirm it hasn’t been altered in transit. Combining DKIM with SPF, most email between well configured sites is now authenticated as well as being encrypted in transit.

Email senders are willing to make the effort because it makes their email display better in popular sites and be less likely to be marked as spam.

We make it very easy for all our users, including those with their own domains, to have their email signed with DKIM which protects the integrity of messages in transit.

End-To-End Encryption

Which brings us to end-to-end encryption, where even the users’ mail providers (aka, us) don’t have access to the plaintext of emails.

Pretty Good Privacy (PGP) itself is a commercial program, but when people say PGP they mostly mean The OpenPGP Standard (RFC4880) so for the rest of this document, when I say PGP I will mean the standard protocol.

PGP is the most popular way of end-to-end encrypting emails.

PGP offers two things, encryption and signatures. These are both stronger guarantees than those offered by DKIM and SPF, iff (if and ONLY if) you manage your key store and web of trust well. Otherwise you’re just pulling keys from a keyserver.

And perfect forward secrecy isn’t a thing with asynchronous communications like emails, so you’re creating a pool of messages which will all be broken at the same time if your key ever leaks, which is why the current gold standard for secure messaging is real time end-to-end instant messaging apps that delete messages after reading.

What’s the tradeoff?

If the server doesn’t have access to the content of emails, then it reverts to a featureless blob store:

• Search isn’t possible
• Previews can’t be calculated
• If you lose your private key, we can’t recover your email
• Spam checking on content isn’t possible
• To access mail on multiple devices, the private key needs to be shared securely between them

Our great replication, availability and backups still work of course, but you lose a lot of the value that Fastmail provides in exchange for not trusting our servers.

Maybe you want to make that trade, so let’s consider the potential threats:

Threat modelling

The fundamental questions: who is a plausible attacker, what are their motivations, what is their budget, what is their risk if caught?

Some of the best security information is found in humour, it’s definitely worth having a read of this masterpiece (pdf) by James Mickens.

If you have an attacker with a budget of millions of dollars trying to get into your email specifically, you need very tight operational security. You’ll want the plaintext of messages displayed for a short time in software with minimum complexity, and you definitely don’t want to be seduced by a secret agent or hit with a $5 wrench, which would bypass the email channel entirely.

Alternatively, you may be concerned about being caught in a dragnet, where an attacker (potentially a state-sponsored entity) wants to scan everyone’s email, and you suspect that they may have compromised your provider or be scanning your provider’s uplinks. That’s a realistic threat, so let’s look at it in more depth.

If we implement PGP, would that protect against server compromise?

PGP could be implemented purely in the browser, or running on our servers. Clearly if it’s running on our servers then either we have the key, or you send us the key every time you read your email.

Pretty much every user accesses their email every day, so within a day of a server compromise, most private keys would be compromised.

If it’s running in the browser with code downloaded from our servers, then if we get compromised, we can serve up a version of the PGP code which leaks keys or plaintext. Game over.

Either way, if you’re trusting code from somewhere for your crypto, you’re trusting that somewhere not be compromised.

Even key management is not something we could do for you. You need to maintain your own web of trust on machines that you trust, or you can be subverted to encrypt secret messages to a different key, one controlled by an attacker.

In summary - there’s no way for us to provide PGP or similar encryption technology to you that’s immune to a compromise of our service.

If we implement PGP, would that protect against wiretaps?

This is more interesting. If you trust us with your key, we could do the PGP crypto for you and check signatures for you.

This is something that’s on our roadmap as a potential feature. In this case it makes sense from both a usability standpoint (interoperability with others who use PGP), and from a sane threat model standpoint.

Certainly relating messages and showing that they have been signed by the same key and hence are from the same person (by keeping full key fingerprints in an addressbook VCARD or similar) could be a useful thing.

But key management is hard, and explaining how it works is hard, and there’s a very small set of users in the gap between those who don’t care about PGP at all, and those who care enough to do it themselves.

Usable crypto is about the whole process

We’re not interested in building something and claiming it as a security feature unless we are providing a real security benefit for users. We don’t see a way to do that right now with PGP. Not securely enough to be worth the complexity (and it’s not zero sum, added complexity often opens up new security risks.)

You can’t just automatically “turn on encryption” and become secure. Data is as secure as the weakest link in the chain.

If you have a strong need for end-to-end encryption, then you need to be controlling the entire environment. Regardless of what we do, you need to make sure your endpoint devices (phones, computers, etc) are secure, because they will be displaying the plaintext, and are part of the security chain. You also need to be certain that your correspondent is practicing equally good hygiene.

For maximum security you should be doing the encryption yourself - either running a tool entirely independently and copy-pasting ciphertext to our web interface on your secure machine, or by running an IMAP/SMTP (or hopefully one day JMAP) client to communicate with our servers and only transferring pre-encrypted emails over those protocols. At which point Fastmail are just a blob store and forward service.

Using PGP with Fastmail

We’re fine with being a blob store for you, you’ll still be using and paying for our rock solid storage backend, replication, backups, availability, etc - you’ll just be missing out on the rest of our features.

We definitely support you running PGP on your own secure machine and using that with our service.

There will be another blog post later in this Advent series explaining ways you can integrate PGP with Fastmail.

*This is the tenth post in the 2016 Fastmail Advent Calendar. *