Is encrypted e-mail sent over TLS 1.3 a form of "forward secrecy" (similar to something like Signal)?

Question

One common complaint about GPG-encrypted e-mail is that it doesn't provide forward secrecy; however with opportunistic TLS becoming increasingly common in both IMAP and SMTP, it's not unreasonable to expect that e-mail sent from one message transfer agent (MTA) to another is done over a TLS protocol that utilizes (EC)DHE—by far the biggest e-mail provider, Gmail, is configured to send and receive e-mail this way by default. Thus if communication between mail user agents (MUAs) and message submission agents, MUAs and message delivery agents, and MTAs and MTAs is done using such a protocol (e.g., TLS 1.3); then even if the GPG key that was used to encrypt the e-mail is fairly static, shouldn't this constitute as "forward secrecy"?

It seems to me that the only way to decrypt someone else's e-mail is if the end-point device has been compromised. This is also true for Signal though. Am I mistaken?

Answer 1

Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of past sessions are deliberately kept around for long periods of time. Instead, you should ask: Who has the data, who has the decryption keys, and when can the decryption keys be erased?

Suppose Alice decides she wants to send a message to Bob, and types it into her laptop.

Let's look at the flow of data in email.

1. Alice's laptop sends the message to Alice's MTA outgoing.oohay.com over the internet, encrypted.
   • The decryption keys between Alice's laptop and Alice's MTA outgoing.oohay.com can be erased after this step, but now outgoing.oohay.com necessarily has a plaintext copy of the message.
2. outgoing.oohay.com sends the message to Bob's MTA incoming.oogleborg.com over the internet, encrypted.
   • The decryption keys between outgoing.oohay.com and incoming.oogleborg.com can be erased after this step, but now incoming.oogleborg.com necessarily has a plaintext copy of the message.
3. A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the message from incoming.oogleborg.com over the internet, encrypted.
   • The decryption keys between Bob's workstation and incoming.oogleborg.com can be erased after this step, but erasing the keys for the TLS sessions doesn't help with the plaintext copies that were left on Oohay and Oogleborg's servers!

If Alice's message is an OpenPGP-encrypted message, then you also need to answer: When does Bob erase all copies of his decryption key? If it's not before Bob's laptop is compromised, then even if Bob has deleted old email messages, an adversary can use Bob's decryption key to decrypt ciphertexts of old email messages.

In contrast, here's the flow in Signal.

1. Alice's laptop encrypts the message and some ratcheting administrivia using her current key for Bob, and sends it to the Google mothership for distribution.
   • The Google mothership necessarily has a ciphertext copy of the message, and needs no keys.
   • Alice can now turn her ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership.
   • After this point, if Alice has followed the protocol, only Bob has the key to decrypt the ciphertext or any way to derive it.
2. A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the ciphertext from the Google mothership.
   • If the ratcheting administrivia shows the messages are in order, Bob can now turn his ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership. (If the messages were delivered out of order, Bob has to hang onto the decryption key for a little longer.)
   • After this point, if Alice and Bob have followed the protocol, nobody has the key to decrypt the ciphertext or any way to derive it.

If Bob decides to delete old Signal messages (e.g., with ‘disappearing messages’, which are, of course, voluntary requests for the peer to respect, and which it is good etiquette to respect), then future compromise of Bob's workstation still isn't enough to decrypt ciphertexts of old Signal messages.

---

Could Bob rapidly rotate his OpenPGP encryption key pairs to achieve a similar effect? Yes—if he erases them that's enough to prevent decryption of past ciphertexts. But there's no OpenPGP tooling to do this automatically, and OpenPGP is enough of a pain to deal with without rolling keys over every Thursday that approximately nobody wants to deal with it, and there's certainly nothing in the protocol to automatically roll keys over after every message while also handling reasonable out-of-order delivery.

That's because OpenPGP was—from a modern perspective with the benefit of hindsight—designed as a toy for early '90s crypto nerds to spend all their time reconfiguring their email clients to handle, mashing ‘signature’ and ‘encryption’ together like LEGO bricks, rather than a protocol to facilitate human interaction like Signal with security goals studied in the cryptography literature.

To be fair to the early PGP designers, a good deal of crucial cryptography literature was evolving concurrently with the development of PGP during the '90s—but even when confronted with basic cryptographic problems in the protocol for humans, the designers abdicated responsibility for addressing them in 2001. Despite contemporary literature on exactly how to address it, to this day OpenPGP doesn't support public-key authenticated encryption. OpenPGP didn't even achieve what has for two decades been the cryptographic standard security notion of public-key encryption until 2018 when EFAIL persuaded the OpenPGP world to begrudgingly make the MDC mandatory—a decade and a half after being alerted to problems with the MDC in 2002.

Answer 2

It seems to me that the only way to decrypt someone else's e-mail is if the end-point device has been compromised.

There is no end-to-end encryption with the usual email delivery using SMTP. Any MTA on the way from the sender to the recipient can read the mail since the encryption is only done between the MTA (if at all) and not end-to-end between sender and recipient. Also the mail is then stored at the last MTA before the recipient retrieves it using POP3 or IMAP (and in the latter case it usually stays at the server too).

Also neither sender nor recipient have control about this delivery process, i.e. if encryption is used in the first place, which TLS version and kind of key exchange is used (forward secrecy or not), if certificates are properly checked etc.

Signal instead is true end-to-end encryption between sender and recipient.

Answer 3

It can be, but only if the sender and recipient are both using email in a presently unconventional way. As someone working on tooling for exactly the kind of thing you're asking about, I hope it will become less "unconventional" at some point, but I'm not holding my breath.

Typically, email users send outgoing mail through an outgoing SMTP server operated by their ISP or email provider (or even through a webmail service). When doing so, this server necessarily sees and can record the unencrypted (or, in your case, encrypted only by PGP but without the forward secrecy of TLS) message. This can be avoided by not using an outgoing SMTP server, but instead having your sending process lookup the receiving mail exchanger (MX) for the recipient's domain via DNS, and delivering directly to it.

Unfortunately, the prevalence of email spam over the past 2+ decades led to many ISPs blocking the outgoing SMTP port, except to their own outgoing server (see above), and also led to most domains' MX servers blocking incoming SMTP connections from IP ranges listed by [extortion rackets posing as] anti-spam organizations as belonging to "dialup"/"dynamic"/"residential" internet users. However, you can of course make SMTP connections to the recipient domain's MX just by tunneling through an IP addresss that's not blocked (e.g. a commercial hosting provider), with the TLS endpoint still local to your end and the host you're tunneling through unable to see the plaintext traffic.

Note that there is also a possibility for interception at the recipient's domain's MX, assuming it's operated by a third party. When making the TLS connection to deliver mail to it, it controls the TLS certificate, private key, and has the power to retain any ephemeral keys. However, if the recipient owns the domain and is operating their own receiving server, then no third parties are involved and, if you send directly to their MX (and enforce DNSSEC validation to ensure that you're actually using the right MX), you really do have end-to-end, with forward secrecy, encryption of email, with secrecy properties comparable to Signal.

So in summary, you can construct e2ee with forward secrecy for email, but it requires both heavy attention to getting it right from both the sender and receipient, and requires the receipient have their own domain and control over all the receiving infrastructure.

Answer 4

You cannot have "forward security" over a saved message - well, you save it in order to read it afterwards. If the legitimate receiver has any means to read it, someone obtaining the receiver's keys can read it as well.

Signal and similar apps deal with the saved messages by simply deleting them after some time. (It's a bit complicated, but the effect is that the message is gone for good.)

It is the communication that you can have "forward security" over. TLS session ends, session keys are gone, because no one needs them anymore. You cannot decrypt the TLS session even if you have the private keys of both parties.