On Sun, Mar 15, 2026 at 11:40 PM Yaroslav Rosomakho <yrosomakho= [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]
