Hi Eric, I did make an effort to go through the thread, but I have to admit that the arguing seemed really dense and I couldn’t really find any compelling reasoning. It felt like a bunch of people shooting off in different directions.
But the core thing is that I didn’t really see anyone explicitly demanding Recommended=N. The AD’s comments were basically “Recommended=Y will cause a huge headache so let’s just push it quickly with Recommended=N”: https://mailarchive.ietf.org/arch/msg/tls/A3rMGGlJKSOvMhRy-NGfPzcpzkU/ From my perspective this all seems rather dysfunctional. But that aside, if hybrids are Recommended=N, and ML-KEM-only key agreement is also Recommended=N, then doesn’t that kind of destroy the meaning of the entire Recommended value assignment? Nadim Kobeissi Symbolic Software • https://symbolic.software > On 23 Feb 2026, at 1:31 PM, Eric Rescorla <[email protected]> wrote: > > > On Mon, Feb 23, 2026 at 4:29 AM Nadim Kobeissi <[email protected]> > wrote: >> That’s interesting. Why were hybrids published with Recommended=N? > > Formally, because there was no consensus to make them "Recommended=Y". > > I would refer you to the thread I linked to which contains the various > arguments > people offered for each outcome. > > -Ekr > > >> >> Nadim Kobeissi >> Symbolic Software • https://symbolic.software <https://symbolic.software/> >> >>> On 23 Feb 2026, at 1:06 PM, Eric Rescorla <[email protected] >>> <mailto:[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] <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]
