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 > > <https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&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]
