I support making the change to prohibit key share reuse, I have no specific opinion on the text.
On Wed, Mar 18, 2026 at 9:46 AM Viktor Dukhovni <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
