I am mostly indifferent to whether this document is eventually published, though sad that we're spending so much time debating it in the WG, given the relatively minimal practical effect of publication. Specifically:
- The code points have already been registered - This document is to be published as Innformational with Recommended=N. It's not clear to me that the publication or non-publication of this document will have much of an impact either way on the deployment of this mechanism. With that said, I believe that the current document has some issues which need to be addressed if it is to be published S 1.1. FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum [RFC9794] key establishment via a lattice-based key encapsulation mechanism (KEM). This document defines key establishment options for TLS 1.3 that use solely post-quantum algorithms, without a hybrid construction that also includes a traditional cryptographic algorithm. Use cases include regulatory frameworks that require standalone post-quantum key establishment, constrained environments where smaller key sizes or less computation are needed, and deployments where legacy middleboxes reject larger hybrid key shares. I don't think this middlebox text is really on point. If we look at John Schauman's helpful breakdown of a hybrid CH that offers both X25519 and X25519/Kyber768, we see that the total CH is 1815 octets. Swapping out the hybrid for MLKEM-768 would buy you 23 octets, which doesn't change things materially. If we were to swap to MLKEM-512, this would buy us another 384 octets, so assuming I'm doing the math right, just that change gets us down to 1431 bytes, so it's *just* possible that this might be large enough to push you into two packets in some cases where the rest of the CH was appropriately sized. I'm skeptical that this is going to be very frequent, especially in light of the fact that at least the CNSA profile 2.0 [0] requires ML-KEM 1024, which has a 1568 byte key, thus putting us squarely in the zone of two packets with or without a hybrid. [0] https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-02.html S 4.2. As a number of people have observed, much of this text repeats text in 8446 and contradicts the negotiation algorithm there, which depends on the group list, not the key shares. You should remove everything up to the graf that starts "For the client's share". S 4.3. Here too, the diagram seems duplicative, so I would remove it. The shared secret output from the ML-KEM Encaps and Decaps algorithms over the appropriate keypair and ciphertext results in the same shared secret shared_secret as its honest peer, which is inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, as shown in Figure 1. I don't know what "honest" is doing here. If you connect to a malicious peer, you might still get a shared secret. S 5.2. While it is recommended that implementations avoid reuse of ML-KEM keypairs to ensure forward secrecy, implementations that do reuse MUST ensure that the number of reuses abides by bounds in [FIPS203] or subsequent security analyses of ML-KEM. Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts. This kind of normative language doesn't belong in Security Considerations. If it's important it should go elsewhere. -Ekr [0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.png On Thu, Feb 12, 2026 at 11:06 AM Joseph Salowey <[email protected]> wrote: > 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]
