For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and make that the default choice. We would like X25519MLKEM768 published as an RFC, be RECOMMENDED=Y, and MTI asap. This is already the de facto standard. All standalone ECC (secp256r1, secp384r1, x25519, x448) should soon be made RECOMMENDED=N and secp256r1 and x25519 should soon be removed from MTI.
We want standalone MLKEM1024 for customers wanting compliance with CNSA 2.0. We are fine with RECOMMENDED=N, but we would like it published as an RFC. We don’t see any need for SecP256r1MLKEM768 at all, I think that should stay RECOMMENDED=N. In the future we would like to see one or more backup algorithms (BIKE, Classic McEliece, FrodoKEM, HQC, etc…) to MLKEM standardized and some of them hybridized with X25519 be made RECOMMENDED=Y. Cheers, Another From: Andrey Jivsov <cry...@brainhub.org> Date: Friday, 6 December 2024 at 21:45 To: TLS@ietf.org <tls@ietf.org> Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement I second D.J. Bernstein's concerns, but my other issue with giving options like this is that they will creep up into MTI sets or default sets, with higher priority than hybrids. I find it less ideal that the document on pure ML-KEM (or signature) and hybrids are disassociated, causing the progress of standardization of the pure version to bring these other concerns. So, as long as everyone is on the same page that pure is just one option, perhaps for strict compliance with CNSA 2.0, then there is no issue from my perspective, but that's a (mildly) controversial part. On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein <d...@cr.yp.to<mailto:d...@cr.yp.to>> wrote: Scott Fluhrer (sfluhrer) writes: > I understand that people want to discuss the hybrid KEM draft more > (because there are more options there) - can we at least get the less > controversial part done? See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather than ECC+PQ, would incur security risks without improving deployment. Regarding "less controversial", you might have missed previous TLS WG messages such as https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/ https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/ https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/ where various people (including me, obviously) already objected. Also, you might have missed BSI writing in https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile that its post-quantum KEM recommendations are only "in combination with a classical key derivation mechanism"; commentator Matt Green writing in https://x.com/matthew_d_green/status/1742521204026622011 that NSA's "stance against hybrid encryption makes absolutely zero sense"; and NSA itself in https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf asking for two cryptographic layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation". ---D. J. Bernstein _______________________________________________ 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
