The support for this change is clearly overwhelming, but I'm still confused about the motivation.
In Happy Eyeballs v3 (and many modern clients), TLS and QUIC connection setup races in parallel. (Racing between multiple TLS or multiple QUIC connections is also possible.) Requiring separate keyshares for each of these connection attempts doesn't improve key separation or forward secrecy, but it does meaningfully increase the client's CPU cost. --Ben Schwartz ________________________________ From: Thom Wiggers <[email protected]> Sent: Tuesday, March 17, 2026 5:06 AM To: Martin Thomson <[email protected]> Cc: <[email protected]> <[email protected]> Subject: [TLS] Re: Prohibiting key share reuse Hi all, I very much agree that independent key shares would be better for security. I wish we’d be mandating proper forward secrecy, but that’s a bit tough to truly mandate. I do want to note that assuming Hello.random are unique (instead of making assumptions on the distribution of keygen) is already the approach taken by e.g. the Dowling et al. analysis of TLS 1.3. That Hello.random are “good enough” for session separation is already encoded in (several) proofs for TLS 1.3. In fact, considering Nick’s clarification: "It does not rule out implementations generating related shares from shared secret material since that is not visible to the client. This change enforces non-reuse, not independence of key shares.” This being allowed means that I still can’t make easy assumptions on the distribution of randomly generated key shares, so security proofs of TLS 1.3 would probably not be improved by this. (Though it should be noted that most _do_ currently assume actual ephemeral key exchange.) Regards, Thom > Op 16 mrt 2026, om 05:24 heeft Martin Thomson <[email protected]> het > volgende geschreven: > > Proposal: > > Prohibit key share reuse in TLS 1.3. > > Reason: > > TLS security depends on uniqueness of key shares. In ECDH, it can be > sufficient for one peer to generate a fresh share. However, a recommendation > against reuse does not prevent BOTH peers from reusing shares. In that case, > session transcripts will only be divergent based on > {Client|Server}Hello.random. The shared secrets will be duplicated between > connections. This is a bad outcome. > > Fixing that could be achieved with signaling or rules. ... or simply > prohibiting key share reuse. The reasons we tolerated reuse in the past > remain, but their relevance has faded: it is now more likely the case that > fresh keygen for every connection is sufficiently cheap that the added code > for reuse isn't worth it. > > Logistics: > > TLS 1.3 is in AUTH48. So this isn't trivial from a procedural perspective. > However. I think that this is trivial from a text perspective. I think that > it's worthwhile if possible. > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
