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