Ephemeral key reuse is a performance feature of TLS stacks, at least it used to be. See e.g. https://mailarchive.ietf.org/arch/browse/cfrg/?gbt=1&index=oMS8YfLOWSBlHMFm7pBeJobafrA , where DJB described one product and supported reuse. I know of another big vendor who did the same.
I think that the new language is OK, but I am surprised that there was enough support for such a tighter language. In any case, punishing servers for reuse would be unwise IMO. On Tue, Mar 17, 2026 at 8:41 PM Viktor Dukhovni <[email protected]> wrote: > 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]
