Well, I am on the same page that ‘pure ML-KEM’ should be one option. While I would agree with you that hybrid makes sense (and should be another option), I am not as inclined as some people to say “and that is so clearly the right trade-off that we should forbid any other option”. There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that’s what they’re willing to buy. Hence, Cisco will implement it; I am essentially just asking for code points.
As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen (barring Q-day happening and the current hybrid key exchanges no longer making sense). As for people implementing it instead of hybrid, well, the working group can help to prevent that by moving ahead with the hybrid draft (hint, hint). From: Andrey Jivsov <cry...@brainhub.org> Sent: Friday, December 6, 2024 3:44 PM To: 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<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
