On Sunday at the TLS:DIV workshop I presented a summary of findings of a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. Thanks to feedback in the room I've now tightened up the findings from the review and posted them as an issue on the draft GitHub repo:
https://github.com/tlswg/tls13-spec/issues/1001 I'll summarize the summary: Naturally the focus was on forward secrecy and replay. On forward secrecy the main finding was that it's not necessary to trade off Forward Secrecy and 0-RTT. A single-use session cache can provide it, and with the modification that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-auth tickets, and it allows clients to build up pools of meaningfully distinct tickets. There's also an observation there that it should really be that clients "MUST" use tickets only once. Any re-use likely discloses the obfuscated ticket age, which is intended to be secret. Right now it's a "SHOULD". On replay, the main finding is that what's in the draft is not workably secure, and the review includes 5 different attacks against 0-RTT data to illustrate that. Attacks 1 and 2 show that the kind of replay permitted by the draft is very different from the kind of replay permitted by dkg's existing downgrade-and-retry attack. I also go over why it very very difficult to many applications to achieve that idempotency, and why one idempotency pattern actually relies on non-replayable messages. Attack 3 shows that idempotency is not sufficient, applications must also be free of measurable side-effects, which is not practical. Attack 4 shows that 0-RTT breaks a common security mechanism: spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability enables an additional form of traffic analysis. The recommendation in the review is that implementations "MUST" prevent replays of 0-RTT section, with some additional discussion about why the existing advice is unlikely to be followed, and why consistent interoperability matters here. Unfortunately, I wasn't aware until Friday that this review would be coming so late in the TLD1.3 draft process, and my apologies for that. I am now planning to attend the future WG in-person meetings and look forward to seeing many of you there. -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
