Andrei Popov wrote: >I'm with Viktor on this one, however don't see a reason to object to a >feel-goodchange.
Very strange to call this a "feel-good change" as reuse of key shares very clearly is a privacy issue. Cheers, John Preuß Mattsson From: Andrei Popov <[email protected]> Date: Thursday, 19 March 2026 at 12:22 To: [email protected] <[email protected]> Subject: [TLS] Re: [EXTERNAL] Re: Prohibiting key share reuse I'm with Viktor on this one, however don't see a reason to object to a feel-good change. Windows TLS stack does reuse key shares for 30 sec. by default, on the server side only (therefore, this does not affect KEM-based PQ KEX). Can be configured for zero reuse, at a perf penalty. As ECDHE keygen is optimized/becomes faster, we will shrink reuse time default and (eventually) eliminate reuse altogether. It is also possible that ECDHE KEX may become irrelevant before this happens, making the entire issue moot. Cheers, Andrei -----Original Message----- From: Viktor Dukhovni <[email protected]> Sent: Wednesday, March 18, 2026 11:42 AM To: [email protected] Subject: [EXTERNAL] [TLS] Re: Prohibiting key share reuse On Tue, Mar 17, 2026 at 08:56:32AM -0700, Eric Rescorla wrote: > On Tue, Mar 17, 2026 at 8:01 AM Viktor Dukhovni > <[email protected]> > wrote: > > > On Tue, Mar 17, 2026 at 01:09:22PM +0000, Ben Schwartz wrote: > > > > > The support for this change is clearly overwhelming, but I'm still > > > confused about the motivation. > > > > FWIW, I just don't have the energy to object to every well-meaning, > > but counterproductive proposal. And it can be uncomfortable to > > uphold a minority view... > > > > I agree that reuse of keyshares across multiple connections should > > generally be avoided, which is the status-quo in RFC8446, but there > > are sometimes just exceptions. An unenforceable MUST NOT may feel > > like progress, but it may do more harm than good. > > > > "May" is doing a lot of work here. > > Do you have some actual substantive argument to offer? The specification already correctly discourages reuse, changing this to a MUST, especially when enforcment on the receiving end is neither very practical, nor wise, rather like a feel-good exercise. And though I don't have a compelling example of reuse in mind, if a particular client stack or deployment finds sound reasons to reuse a keyshare across multiple connections (perhaps closely spaced in time, or happy eyeballs, or some other just reason) I don't think it is appropriate to put roadblocks in their way. The problem this proposed "MUST" is solving is essentially non-existent, mainstream TLS software stacks and deployments already don't use long-term keys for ephemeral key exchange. I do however recall (I hope accurately, apologies if this is fiction) that Microsoft's TLS may under some conditions reuse ephemeral keys briefly for connections that are closely spaced in time. There's nothing fundamentally wrong with that, assuming they've done their homework. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ 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]
