> I don't think this middlebox text is really on point. That text has already been removed as of -07
On Sat, Feb 21, 2026, 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
