It shouldn’t’ve been necessary - but since common sense isn’t that common (anymore?), I support this.
— Regards, Uri
Secure Resilient Systems and Technologies MIT Lincoln Laboratory
I support this. On Mon, Mar 16, 2026 at 5: 25 AM Martin Thomson <mt@ lowentropy. net> 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
I support this. 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]
|
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
