That’s great! Thank you for taking the initiative. Please let me know if I can help.
Nadim Kobeissi Symbolic Software • https://symbolic.software > On 23 Feb 2026, at 1:47 PM, Bas Westerbaan <[email protected]> wrote: > > I'm drafting an I-D now. > > On Mon, Feb 23, 2026 at 1:45 PM Nadim Kobeissi <[email protected]> > wrote: >> 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 <https://symbolic.software/> >> >>> On 23 Feb 2026, at 1:42 PM, Bas Westerbaan <[email protected] >>> <mailto:[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]
