I also support prohibiting key share reuse

________________________________
From: David Schinazi <[email protected]>
Sent: Monday, March 16, 2026 5:42 AM
To: TLS List <[email protected]>
Subject: [TLS] Re: Prohibiting key share reuse

I also support this change.
David

On Mon, Mar 16, 2026 at 4:49 PM Pascal Urien 
<[email protected]<mailto:[email protected]>> wrote:


Le lun. 16 mars 2026, 05:25, Martin Thomson 
<[email protected]<mailto:[email protected]>> a écrit :
Proposal:

Prohibit key share reuse in TLS 1.3.

Reason:

TLS security depends on uniqueness of key shares.

Not always. true when pre_shared-key is used with ECDH or without ECDH

Pascal


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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to