[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

>>> This is equivalent to asking, in 1979, whether anyone is aware of weaknesses
>>> in RSA.
>>
>> RSA was published in 1977, and predating it DH — in 1976.
>
> Precisely. ML-KEM has been in use, mostly due to being baked into the
> Chromium monoculture, for around two years now.
>
> 1979 - 1977 is also around two years last time I checked.
> Unlike your values, I didn't just pull the value 1979 out of thin air.

The arithmetic is not the problem; the choice of starting point is.

You are counting time since broad browser deployment and treating it as time
available for public cryptanalysis. Those are not the same quantity.

Kyber did not become available for analysis when Chromium enabled
X25519Kyber768/ML-KEM in TLS. Kyber was public in the NIST PQC process in
November 2017, selected for standardization in 2022, and standardized as
ML-KEM in FIPS 203 in 2024. If one wants an RSA analogy, the relevant clock is
the public cryptanalytic clock, not the Chrome release train.

So yes, "1979 - 1977 = 2" is correct. The sleight of hand is pretending that
the corresponding ML-KEM clock starts at Chromium deployment rather than at
Kyber's public submission and subsequent NIST review.

It is also worth being precise about the proof claim. Nobody is claiming a
proof that Module-LWE is hard. The point is that ML-KEM has machine-checked
proof work connecting the specified construction to explicit assumptions, and
implementation-correctness work connecting implementations to the
specification. That is a materially stronger evidentiary position than "has
anyone heard a rumor of a weakness?"

If your claim is only that ML-KEM has had about two years of high-volume
browser deployment exposure, fine. If your claim is that ML-KEM has had only
about two years of public cryptanalytic exposure, that is simply false.