> Can you please point to the "regulatory requirements" you have in mind, and > explain why you believe that the requirements prohibit X25519MLKEM*? A few other examples have been posted on the thread; my primary concern is CNSA-compliant environments.
https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF table IV requires "Level V parameters" for all classification levels, which means ML-KEM-1024. https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF table V requires P-384 for all CNSA classification levels. X25519MLKEM768 satisfies neither requirement. > The NIST rules for hybrid key exchange, which changed a few times, are now as > long as one of the two is validated (in either first or second position) they > whole exchange is okay. So yes, if you only have P256/384 validated, then you > must include that in your hybrid exchange with ML-KEM. This is my understanding also, however I would not be comfortable advising that X25519MLKEM768 is FIPS-compliant because its MLKEM768 component is validated. Cheers, Andrei -----Original Message----- From: D. J. Bernstein <[email protected]> Sent: Friday, October 10, 2025 9:02 AM To: [email protected] Subject: [EXTERNAL] [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Andrei Popov writes: > There are regulatory requirements that require NIST curves, whether > one likes them or not. Can you please point to the "regulatory requirements" you have in mind, and explain why you believe that the requirements prohibit X25519MLKEM*? Some reasons that I'm skeptical that there's an important issue here: * Reportedly >80% of TLS is already using X25519. * Reportedly ~40% of clients and ~30% of servers already implement the X25519MLKEM768 option in this draft, while ~0% implement the other options in this draft. * My understanding is that NIST now approves hybrids of _anything_ (as an "OtherInput" inside a hash) with ML-KEM, although I haven't checked the details here. Sources: https://mailarchive.ietf.org/arch/msg/tls/lWh_uimMIgQ6SMV_BSkJDh34eQM/ https://mailarchive.ietf.org/arch/msg/tls/vWAEg7E3jeLZjLABVaMVLR0flX4/ https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption https://www.netmeister.org/blog/pqc-use-2025-03.html https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf ---D. J. Bernstein ===== NOTICES REGARDING IETF ===== It has come to my attention that IETF LLC believes that anyone filing a comment, objection, or appeal is engaging in a copyright giveaway by default, for example allowing IETF LLC to feed that material into AI systems for manipulation. Specifically, IETF LLC views any such material as a "Contribution", and believes that WG chairs, IESG, and other IETF LLC agents are free to modify the material "unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)". I am hereby explicitly disallowing such modifications. Regarding "form", my understanding is that "Legend Instructions" currently refers to the portion of https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf saying that the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC" must be expressed in the following form: "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft". That expression hereby applies to this message. I'm fine with redistribution of copies of this message. There are no confidentiality restrictions on this message. The issue here is with modifications, not with dissemination. For other people concerned about what IETF LLC is doing: Feel free to copy these notices into your own messages. If you're preparing text for an IETF standard, it's legitimate for IETF LLC to insist on being allowed to modify the text; but if you're just filing comments then there's no reason for this. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
