Thanks for the citations and text simplification. However, the citation to CNSSP15 fails -- it returns a 'not found' error (specifically, "CNSS.GOV ERROR MESSAGE We're sorry, but we're having trouble opening this document because we did not recognize your session variable. This may have been caused by: Using a bookmark to access a specific part of this site. Not all pages in this site can be bookmarked. [...]"), this from the main branch of the github repository for the I-D (https://github.com/tlswg/draft-ietf-tls-mlkem/tree/main). Considering the cited URL is approximately two miles long, I suspect the problem is it's a bookmarked URL as that error page warns.
https://www.cnss.gov/CNSS/openDoc.cfm?a=kryrfZb9nS00l4L2shjYcQ%3D%3D&b=C944BD2E7ABAA37851D7A7EF71743C3ACE8393115D7588CD4423DD2B918812A86F060A05C2E0D4DEF8456CC75B2D39F4 The www.cnss.gov server is providing a US DoD-specific certificate after I dismiss the untrusted certificate warning (!) and it encourages: "ATTENTION - As of 24 February 2022, all users must install a DoD Root Certificate in their browser in order to access the CNSS website. Please select the following link for more information: DoD Root Certificate Help" I attempted to find a citation and bumped into https://www.cnss.gov/CNSS/issuances/Policies.cfm which shows "CNSSP 15" (with a space, 10/20/2016) and "CNSSP-15" (with a dash, 03/04/2025). It looks like the version with a dash is the intended citation. I can't tell for sure. But I could not find the strings admonishing/warning against hybrid schemes (I searched for 'hybrid' and 'curve' and 'pure' and 'sole' and 'only' and 'traditional'). -d > On Feb 12, 2026, at 2:21 PM, Deirdre Connolly <[email protected]> > wrote: > > I've simplified the respective language there to 'requirements' on the GitHub: > > https://github.com/tlswg/draft-ietf-tls-mlkem/commit/17e815cc847b231125b65c2523bc5535e4034c14 > > <image.png> > > > On Thu, Feb 12, 2026 at 4:57 PM Ben Schwartz <[email protected]> wrote: > Thanks for the updates! Is ITSP.40.111 really a regulation? Like CNSA 2.0, > it seems to be an internal rulemaking within a government, rather than a > regulation that binds the private sector generally. > > --Ben > From: Deirdre Connolly <[email protected]> > Sent: Thursday, February 12, 2026 4:51 PM > To: Russ Housley <[email protected]> > Cc: <[email protected]> <[email protected]> > Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) > Thank you all for reading and replying. I have pushed some changes to the > GitHub repo based on the discussions so far (not to datatracker yet): https: > //github. com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05. . > main (the tlswg. org > Thank you all for reading and replying. I have pushed some changes to the > GitHub repo based on the discussions so far (not to datatracker yet): > > https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05..main > > (the tlswg.org domain is messed up otherwise i would link the diff based on > the Editor's draft) > > On Thu, Feb 12, 2026 at 4:39 PM Russ Housley <[email protected]> wrote: > I support the publication of this document as an RFC. I would prefer to have > the clarity about ephemeral vs. static ML-KEM keys as posted by John > Mattsson, but I can live with it as-is. > > Russ > > >> On Feb 12, 2026, at 3:08 PM, John Mattsson >> <[email protected]> wrote: >> >> Hi, >> >> I support publication iff all text related to “key reuse” is removed. In its >> current form, I do not believe -07 should be published. >> >> Major Comments: >> >> - FIPS 203 states that: >> >> “the licensed patents be freely available to be practiced by any implementer >> of the ML-KEM algorithm as published by NIST.” >> >> “requirements for the secure use of KEMs in applications, see SP 800-227.” >> >> A reused key is, by definition, a static key. SP 800-227 imposes additional >> requirements for static keys compared to ephemeral keys. The draft does not >> explain how an implementer can satisfy these requirements. This creates >> potential non-conformance with NIST specifications. >> >> - The draft does not describe the significant security and privacy problems >> associated with key reuse. IND-CCA is a theoretical property of the >> algorithm. However, the security and privacy problems are related to the >> reuse of keys in the TLS 1.3 protocol in deployments. >> >> Minor Comments: >> >> - The discussion of randomness reuse in ciphertexts and references to SP >> 800-227 do not belong in a “key reuse” section. Ciphertexts are not keys, >> and SP 800-227 contains broader guidelines and requirements beyond static >> keys. >> >> - “The client's shares are listed in descending order of client preference; >> the server selects one algorithm and sends its corresponding share.” >> >> The server may also select no share and respond with a handshake_failure or >> a HelloRetryRequest (HRR). Since this is already specified in RFC 8446, it >> would be better to remove this text and simply reference RFC 8446. >> >> - Section 5.1 appears to mix different concepts: hybrids, PQ/T hybrids, and >> lattice-based PQ/T hybrids. I assume the person asking for this section >> wanted a comparison with [ECDHE-MLKEM]. I suggest doing that. In the future, >> PQ/T hybrids will likely become less common, but it is unclear whether other >> hybrids (e.g., ML-KEM + HQC-KEM) will gain adoption. >> >> Cheers, >> John >> >> From: Joseph Salowey <[email protected]> >> Date: Thursday, 12 February 2026 at 20:06 >> To: <[email protected]> >> Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) >> >> This message starts the second Working Group Last Call for the pure ML-KEM >> document (draft-ietf-tls-mlkem-07). >> >> The file can be retrieved from: >> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ >> >> The diff with the previous WGLC draft (-05) is here: >> >> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html >> >> The main focus of this WGLC is to review new text providing more context >> around the use of pure ML-KEM. For those who indicated they wanted this >> text, please let us know if the new text satisfies you and if you support >> publication. This working group last call will end on February 27, 2026. >> >> Thank You. >> _______________________________________________ >> 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
