> 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 > > 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 >> >> 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]> 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] >> >> >> > _______________________________________________ > 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]
