On Mon, Feb 23, 2026 at 3:56 AM Kurt Roeckx <[email protected]> wrote:
> The hybrids are also published with Recommended=N. > Yes. You may recall that I argued for "Recommended=Y". https://mailarchive.ietf.org/arch/msg/tls/FK6fpPv4ZWtgkrfftNGuaP-c6Lo/ -Ekr > 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]
