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.
-
Show this 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
1 reply 0 retweets 10 likesShow this thread -
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!
1 reply 1 retweet 10 likesShow this thread -
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.
1 reply 0 retweets 15 likesShow this thread -
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.https://blog.filippo.io/we-need-to-talk-about-session-tickets/ …
1 reply 18 retweets 42 likesShow this thread -
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!
1 reply 0 retweets 18 likesShow this thread -
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.
1 reply 0 retweets 12 likesShow this thread -
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.
1 reply 0 retweets 12 likesShow this thread -
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.
2 replies 3 retweets 12 likesShow this thread -
(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.)
2 replies 0 retweets 8 likesShow this thread
Puncturing doesn't really work if you use a distributed store; you need atomic delete-and-retrieve, so you'd have a large slow transaction span. The stores can be sharded easily though, and the benefit Vs plain session-ids is less memory usage, at the cost of more memory access.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.