I am in favor of changing the SHOULD to a MUST. From an interop perspective, we'd probably have to forbid the peer from enforcing it, however, lest it break implementations which decided that SHOULD meant YOLO.
Should the WG be in favor of this change, I would be happy to manage the document mechanics. -Ekr On Sun, Mar 15, 2026 at 9:25 PM Martin Thomson <[email protected]> wrote: > 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]
