On Thu, Dec 05, 2024 at 02:32:21PM -0800, Watson Ladd wrote:
> 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).
[ This is of course a digression from TLS to the side topic of whether
KEM key reuse is "always bad", after this, I shan't comment on it
further. ]
Sure, but the key that's reused in KEMTLS is the server's public key,
and even the client's keyshare is unique each time, see Figure 2 of:
https://thomwiggers.nl/publication/kemtls/kemtls.pdf
The server's long-term KEM public key is sent to the client encrypted in
a key derived from the KEM shared secret obtained from the encap of the
client's (ideally ephemeral) keyshare public key, and given a random
server nonce, the rest of the handshake is not repeated even if the
client key happens to be reused (a bad choice in general, but perhaps OK
in some narrow use-cases).
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
