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

[Deirdre Connolly <[e-mail]>]

> Also, the text recommending not reusing keys could use RFC 2119  keywords.

Only -bis updates to 8446 can change normative requirements here. This was
already discussed and resolved for earlier documents (I'm pretty sure it
was regarding -hybrid). The latest 8446bis draft (
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html) says
"Clients and Servers SHOULD NOT reuse a key share for multiple connections"
and that will flow down to hybrid kex and non-hybrid kex equally.

On Fri, Feb 27, 2026, 8:17 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey 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.
>
> Some comments:
>
> - The document could expand on impact of key reuse. Known impacts
>   include:
>
>   * Linking connections from the same client, which may be a privacy
>     risk.
>   * Making exploiting side channel attacks and implementation flaws
>     much easier.
>
>   Also, the text recommending not reusing keys could use RFC 2119
>   keywords.
>
>
> - Also the document could expand on applicability. Known use cases
>   include:
>
>   * ML-KEM-512: Constrained systems that nevertheless require security
>     against quantum adversaries. ML-KEM-512 is among the most efficient
>     quantum-resistant key exchanges known (at least among the not-too-
>     exciting ones).
>   * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) in
>     United States. ML-KEM-1024 is the only key exchange in the CNSA2
>     profile.
>
>
> And some notes, mainly on why I disagree with comments that this draft
> should not be published:
>
>
> - There does not seem to be any evidence that ML-KEM is weak. I think
>   that if ML-KEM gets badly broken, it will be for unforeseeable reasons
>   (which is a risk for any cryptographic algorithm, including prime-
>   field ECC).
>
>   This is in contrast to things like RC4, where evidence that it is
>   bad did exist at the time TLS 1.0 was developed.
>
>   Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a
>   serious endorsement.
>
>   I personally think that using hybrids for encryption is worth it, but
>   it is close a call, and I can see that even relatively small weight
>   differences may tip the scale the other way.
>
>
> - I do not think ML-DSA FO design is bad. While possibly not optimal,
>   I think it is very decent. I do not think passing raw entropy is
>   significant problem, as it seems to matter only with backdoored RNG,
>   which is something the extra hash in Kyber can not defend against.
>
>   In short, I think the differences between Kyber and ML-KEM are
>   improvements.
>
>
> - There are already 6 references on the construction, and I did try
>   giving it some good blows myself, obviously that did nothing to
>   stand-alone ML-KEM.
>
>
> So I support publication.
>
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>