Thread by @FiloSottile

I believe the recent efforts to bring Forward Secrecy to TLS 1.3 0-RTT data are far, far into the realm of diminishing returns. Thing is, I don't think FS is that valuable in itself. Thread.

When PFS cipher suites first came along they were a big leap forward in the security of TLS, for two reasons:

1) they provided Forward Secrecy (if you are compromised tomorrow, today's connection is safe) relatively to very long-lived key material—certificates that lasted years

2) less obviously, they provided what we now call Post-Compromise Security (if you are compromised today, tomorrow's connection is safe) against passive attackers

If all an attacker has is your certificate key, with PFS it has to mount a MitM to eavesdrop, which does not scale!

That second property, PCS, is critical in disrupting dragnet surveillance, in particular in today's era of geographically distributed CDNs.

If you can take a small key from a machine in country X and use it to _passively_ decrypt all traffic to a website globally, it's Bad News.

So PFS cipher suites were good, but then Session Tickets were implemented in the worst way possible and messed it all up again. Now there is again a key of unspecified lifetime with passive decryption capabilities.

I wrote about it some time ago. blog.filippo.io/we-need-to-tal…

Anyway, TLS 1.3 does it all right instead:
1) it caps the Session Ticket Encryption Key lifetime to 7 days and
2) it allows a Diffie-Hellman exchange on resumption, bringing back Post-Compromise Security.

If all you have is the STEK, you again need to mount a noisy MitM. Yay!

Unfortunately, you have to encrypt the 0-RTT data before the DH exchange, so early data gets no Forward Secrecy relatively to the STEK.

Which brings us to the new schemes to use puncturable encryption (which don't get me wrong, is super cool!) to provide it.

The idea is that you forget the pieces of the key you used to decrypt a certain session ticket after using them.

The problem is that this does not provide any Post-Compromise Security: the attacker that stole the whole key yesterday is not going to forget any of it.

IMHO, the scenario where an attacker quietly extracts a key from a single machine to then passively decrypt traffic is much more likely than the one where the attacker breaks in to decrypt yesterday's traffic. In particular because the lifespan of STEKs is now capped at 7 days.

(Moreover, if you can sync state between your servers to do the puncturing, you might as well do Session IDs instead of Session Tickets, so there's no STEK to begin with, and you get real PFS and some PCS—that is, the attacker has to keep exfiltrating a lot of keys, noisily.)

In conclusion, this is why I hope large scale TLS providers will focus on best practices for localizing and rotating TLS 1.2 STEKs (which are not going anywhere anytime soon) before chasing diminishing returns on PFS-without-PCS. Fin.

(This should have been a blog post, not a thread. Sorry.)