On Thu, Dec 5, 2024 at 7:31 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Sat, Nov 02, 2024 at 07:12:02AM +0000, John Mattsson wrote: > > > Eric Rescorla wrote: > > >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys? > > > > No reuse of ephemeral keys is always bad. > > But ML-KEM is specifically designed (IND-CCA2, via FO transform) to > support key reuse, without immediate advantage to the attacker.
Having two identical Client Hellos is bad for the security proofs in TLS. While MLKEM keys aren't the only part of the ClientHello, (ClientRandom is also), reuse potentially breaks assumptions in the symbolic analysis. That's different from a break of IND-CCA2: IND-CCA2 is fine if you send the same message again and get the same answer, while having two of the same session is a problem for TLS. (What is the meaning of "same"? Good question). > > And (though it isn't exactly TLS 1.3) there are ideas in place like > KEMTLS, in which the server key is actually stable (used as both > a KEM and for authentication, obviating the need for separate signing > of the key exchange). Different things are different. KEMTLS uses an ephemeral KEM key at the very start. Importantly there's a complete (actually two complete) Tamarin proofs of claimed security properties. > > And so long as the client's encap ciphertext is different each time, > there's no issue with linking connections. > > So perhaps the story is a bit more nuanced than "key reuse is always > bad", but of course any design that incorporates key reuse needs to > take care to do it correctly. > > Specifically, in stock TLS 1.3, (with the client side generating keys, > and doing "decap") it seems that key reuse is not particularly > compelling, and servers don't have a key they can reuse, "encap" just > consumes a nonce and the client's public key. > > -- > Viktor. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
