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]
