That’s interesting. Why were hybrids published with Recommended=N? Nadim Kobeissi Symbolic Software • https://symbolic.software
> On 23 Feb 2026, at 1:06 PM, Eric Rescorla <[email protected]> wrote: > > > On Mon, Feb 23, 2026 at 3:56 AM Kurt Roeckx <[email protected] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[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]
