Bas Westerbaan wrote: >BoringSSL (Chrome) generates a new keypair for each connection. We do >too. ML-KEM keygen is quite cheap anyway.
That is great to hear! 👍 Hopefully most implementations follow this. Reusing ephemeral keys are bad for several reasons. It relates the key material in different connections that should not be related. A vulnerability (theoretical, bad implementation like no public-key validation, or side channel) can enable an attacker to listen in to a someone's else connections. Reuse also have significant privacy issues as you suddenly have a fixed cleartext field which is the same in several connections. NIST has very good requirements on this "An ephemeral private key shall be used in exactly one key-establishment transaction". Reusing an ephemeral key is not FIPS compliant. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-56Ar3.pdf I hope that the CNSA 2.0 Profile for TLS 1.3 will forbid this just like the CNSA 1.0 profile did for IPsec. 3GPP had a lot of help form the CNSA 1.0 profiles. https://datatracker.ietf.org/doc/rfc9206/ I also hope a future update of TLS will forbid reuse. Cheers, John From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> Date: Friday, 1 November 2024 at 13:33 To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: MLKEM or Khyber KX BoringSSL (Chrome) generates a new keypair for each connection. We do too. ML-KEM keygen is quite cheap anyway. On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>> wrote: Are folks generating a new key every connection or just using a longer-lived keypair and not re-using the random? _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
