CNSA 2.0 does not support hybrids in general, and their TLS profile only supports ML-KEM-1024: https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/
On Fri, Oct 10, 2025, 3:24 PM Andrei Popov <Andrei.Popov= [email protected]> wrote: > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
