I strongly support this charge. Supporting key share reuse in the spec is a poor allocation of WG and implementer resources. It brings into scope timing side channels, invalid curve attacks, and bug attacks, none of which truly matter to TLS, or rather need to.
2026-03-16 07:44 GMT+01:00 Eric Rescorla <[email protected]>: > > > On Sun, Mar 15, 2026 at 11:40 PM Yaroslav Rosomakho > <[email protected]> wrote: >> Is the proposal to change "Clients and Servers SHOULD NOT reuse a key share >> for multiple connections" to "Clients and Servers MUST NOT reuse a key share >> for multiple connections" in the appendix C.4? >> >> If so, I support such change. > > Yes. > >> It would be great to keep allowing key reuse within the same handshake. I >> don't see a crime in using the same 32-byte public X25519 key within X25519 >> and X25519MLKEM768 keyshares of the same ClientHello or two ClientHellos in >> the same connection after HRR. Some implementations do that today. > > I don't love this practice, but I think the sense of the WG was to allow > this, and I don't think this change would prohibit it. > > -Ekr > >> >> Best Regards, >> Yaroslav >> >> On Mon, Mar 16, 2026 at 12: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] >> >> >> This communication (including any attachments) is intended for the sole use >> of the intended recipient and may contain confidential, non-public, and/or >> privileged material. Use, distribution, or reproduction of this >> communication by unintended recipients is not authorized. If you received >> this communication in error, please immediately notify the sender and then >> delete all copies of this communication from your >> system._______________________________________________ >> 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]
