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]
