Hi, I missed this thread, but Ericsson put a lot of effort on this topic in our recent comments to NIST, which might be of interest for people in TLS WG:
https://emanjon.github.io/NIST-comments/2025%20-%20SP%20800-227.pdf https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/ml-kem-is-great-paper.pdf https://csrc.nist.gov/csrc/media/Presentations/2025/ml-kem-is-great/images-media/ml-kem-is-great.pdf * Reuse of (EC)DHE key shares _very_ clearly violates NIST requirements. I hope no implementation claiming compliance with NIST is reusing (EC)DHE key shares, and I hope NIST checks this. * Reuse of key shares also goes against zero trust principles. Implementation bugs that allow attackers to recover ECDHE private keys have been common and should be expected. Reuse of "ephemeral" keys transforms such bugs from relatively benign to very serious vulnerabilities. Many governments are pushing very hard for zero trust. Cheers, John From: Sophie Schmieg <sschm...@google.com> Date: Tuesday, 14 January 2025 at 20:19 To: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys I strongly prefer 3. In the ML-KEM spec, the consistency checks on the public keys are marked as optional, so I think it would be a fair interpretation of FIPS 140-3 that the required consistency checks consist of the optionally allowed empty set in the case of ML-KEM. On Mon, Jan 13, 2025 at 7:11 PM Viktor Dukhovni <ietf-d...@dukhovni.org<mailto:ietf-d...@dukhovni.org>> wrote: On Mon, Dec 16, 2024 at 07:02:43AM -0800, Eric Rescorla wrote: > Thanks. It seems like that would imply that Web clients cannot safely > enforce a non-reuse requirement even if we had one. > > Do you plan to reuse ML-KEM keys as well? The situation seems to be > different because, as Scott observes, it's the client who reaps the benefit. It may be worth noting that FIPS 140-3 requires pairwise consistency tests (PCTs) on generated (and imported) KEM keys before first use, with no exception carved out for single-use keys. This factor of 2 or so performance hit[1] on single-use keys does create a temptation to amortise the cost by reusing the key a number of times (for a short time). Haven't taken any steps in that direction at this time. -- Viktor. [1] Instead of keygen + decap, the single use cost becomes keygen + encap + decap + decap. Whether this is more or less than a 2x performance hit depends on implementation details. _______________________________________________ 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> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com<mailto:sschm...@google.com>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
