On Wed, Mar 18, 2026 at 05:59:21PM +1100, Martin Thomson wrote:
> On Wed, Mar 18, 2026, at 14:41, Viktor Dukhovni wrote:
> > 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.
>
> As others have noted, many different analyses of the protocol have
> assumed fresh shares, so the security guarantees rely on having fresh
> shares. So not completely pointless, unless you don't feel like
> security analysis is useful.
Security analysis provides useful guidance, and is especially valuable
when it helps to identify subtle issues that might otherwise be missed.
The general case analysed doesn't always cover all the cases that arise
in practice, but lack of coverage does not necessarily make remaining
use-cases invalid.
For example, ML-KEM (hybrid or standalone) should be robust enough to
allow short-term reuse of a client's ephemeral ML-KEM keyshare.
Suffient additional entropy will be contributed by the server and client
random values as well as the server's ML-KEM ciphertext.
I am not unduly concerned by a potential lack of a formal proof that
such reuse providers the same security guarantees as single-use.
And in any case, since the proposed language has "no teeth", I don't
expect it to matter.
In case someone is worried, there are no plans to add ephemeral key
reuse in OpenSSL, and I am not advocating for that to change. I just
don't see tangible value it the proposed change, it feels to me like
security theatre.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
