The hybrids are also published with Recommended=N. Kurt
On February 21, 2026 11:51:39 PM GMT+01:00, 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]
