I'm in favor of this, if nothing else to close off a distraction on the ML-KEM document. If one's complaint about some codepoint also applies to *every other such codepoint in TLS*, it should be addressed at the core protocol, not relitigated on every codepoint ad nauseam.
On Mon, Mar 16, 2026 at 1:25 PM Loganaden Velvindron <[email protected]> wrote: > I support this change. > > > > On Mon, 16 Mar 2026, 08:25 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
