I support the publication of this draft, and note that Chrome has implemented ML-KEM 1024, currently requiring explicit configuration, and that ML-KEM 1024 can be used to connect to certain Google properties.
I find the remaining word smithing to be at best, a waste of time, and at worst, potentially inaccurate. I recommend the document be published as-is. On Thu, Feb 12, 2026 at 3:10 PM John Mattsson <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]
