> (but AFAIK not banned by TLS). Futhermore, some other security standards like > FIPS do ban share reuse across connections. Yes, FIPS 203 (ML-KEM) forbids the reuse of an ephemeral public key for key-establishment in two connections. Consequently, this will also be prohibited in any IETF standard employing ephemeral ML-KEM keys.
Hopefully, the IETF will reject any proposal to violate NIST requirements merely to accommodate organizations seeking intercept/visibility through discouraged means. There are better ways to achieve visibility without compromising the privacy and security of the Internet as a whole. NIST SP 1800-37 “Addressing Visibility Challenges with TLS 1.3 within the Enterprise High-Level Document” states: “Reuse of a key share allows passive observers to correlate different connections. This specification discourages client and server reuse of a key share for multiple internet connections. Reusing key shares outside protected facilities can also expand the impact of security breaches.” And the above statement from NIST is too soft. If you believe in zero trust rather than perimeter security, reusing key shares can expand the impact of security breaches even within protected facilities. Moreover, reusing key shares also weakens forward secrecy and post-compromise security. Cheers, John From: Ilari Liusvaara <[email protected]> Date: Saturday, 25 October 2025 at 13:36 To: [email protected] <[email protected]> Subject: [TLS] Re: KeyShareEntry MUST be generated independently - was Re: Mohamed Boucadair's No Objection on draft-ietf-tls-hybrid-design-15: (with COMMENT) (fwd) On Sat, Oct 25, 2025 at 01:56:34AM +0100, Stephen Farrell wrote: > > Hiya, > > On 25/10/2025 01:10, Viktor Dukhovni wrote: > > > The text could say: > > > > [TLS13] requires that ``The key_exchange values for each > > KeyShareEntry MUST be generated independently.'' In the context > > of hybrid algorithms, this independent generation requirement > > also applies across its component algorithms. However, when a > > component algorithm of a hybrid keyshare is used in more than > > one keyshare within the same ClientHello, either as part of > > another hybrid, or standalone, that same keyshare component MAY > > be used more than once, since ultimately only one of the > > keyshares is used in key derivation: the multiple copies in the > > same ClientHello do not lead to reuse of an ephemeral private > > key, nor are the secrets for separate algorithms thereby derived > > in a manner than might compromise the security of the stronger > > when the weaker is vulnerable to an attack. > > I'm fine with however this gets resolved, but have a question: would > the above still always be true with ECH? Given the ECH compression > mechanism and the ECH fallback authentication of the `public_name` a > client might use the same private value twice, or am I mistaken? - ECH compression can not lead to reuse, because only one of the client hellos is used. In fact, generating indepndent key shares for both can be a security problem. That is, if there is some component that lacks anonymity (which is normally not a problem) and server chooses that, then passive observer might be able to tell if ECH was used or not. - ECH fallback authentication is separate connection, so it can only lead to reuse if client reuses shares between connections, which is not recommended (but AFAIK not banned by TLS). Futhermore, some other security standards like FIPS do ban share reuse across connections. -Ilari _______________________________________________ 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]
