Hi Deirdre, Given how this is an endless thread and how i guess my sugestions where ignored by you (i did not see any repsonse), i have filed both of them as github issues.
https://github.com/tlswg/draft-ietf-tls-mlkem I can only suggest to others here on the thread that made suggestions for improvements that have simply been ignored through this thread. I also don't think that the adding of analysis references and simply enumerating them in one line in the text as the diff for Ekr now does is sufficient. There needs to be text summarize the DIFFERENCES/BENEFITS over draft-ietf-tls-ecdhe-mlkem - and only then point to appropriate references that detail it. But the summary needs to be in this draft. Cheers Toerless On Mon, Feb 23, 2026 at 08:39:07PM -0500, Deirdre Connolly wrote: > I've pushed basically all of these changes up to github, as well as adding > citations for much of the pertinent work on analyzing KEMs in TLS key > agreement in multiple security models etc > > https://github.com/tlswg/draft-ietf-tls-mlkem/blob/main/draft-ietf-tls-mlkem.md > > On Sat, Feb 21, 2026 at 5:52 PM Eric Rescorla <[email protected]> wrote: > > > > > 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] > > -- --- [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
