On Tue, Mar 17, 2026 at 6:11 AM Ben Schwartz <bemasc= [email protected]> wrote:
> 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. > Really? Do you have some measurements that indicate that this is "meaningful"? On my M4 Mac, X25519+MLKEM keygen is about 41us, seven if I did 10 of them for each connection that would be less than 1ms of CPU time. This is a relatively fast but not ridiculous machine, but even if it were 10x worse, that still wouldn't be a meaningful number for any client I am aware of. -Ekr [0] https://cryspen.com/post/ml-kem-implementation/ > > --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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
