Okay, but in that case, we should expect that there will be a serious effort to move hybrids to Recommended=Y some time this year, right?
This is strongly implied by the AD’s remarks, and leaving them as Recommended=N makes absolutely no sense, especially if you also want to pass their complete opposite as Recommended=N. Nadim Kobeissi Symbolic Software • https://symbolic.software > On 23 Feb 2026, at 1:42 PM, Bas Westerbaan <[email protected]> wrote: > > >> 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. > > This is why we are here and standardization exists. Doesn't mean it's easy. > >> 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? > > There was a desire of many in that discussion not to block the hybrid draft > on the question how to update the Recommended field precisely for all the > hybrid and existing KEMs. To make progress, sometimes you have to decouple > things. > > Best, > > Bas > > > >> >> Nadim Kobeissi >> Symbolic Software • https://symbolic.software <https://symbolic.software/> >> >>> On 23 Feb 2026, at 1:31 PM, Eric Rescorla <[email protected] >>> <mailto:[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] <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]
