[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

[Deirdre Connolly <[e-mail]>]

> This kind of normative language doesn't belong in Security
Considerations.  If it's important it should go elsewhere.

Good point, I'll move this out into something like § 4.2 (fwiw this was
mirrored from -hybrid-design which does have normative language in its
Security Considerations)


On Sat, Feb 21, 2026, 5:52 PM Eric Rescorla <[e-mail]> 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 <[e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>