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 -- [email protected]
To unsubscribe send an email to [email protected]
