[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

[Muhammad Usama Sardar <[e-mail]>]

Hi folks,

I'm concerned that such posts quoting Google and Cloudflare may be 
creating a sense of undue urgency, so I would like to share my study 
with the WG to set the right priorities. FWIW, I strongly believe 
urgency should actually be on recommending hybrids 
(draft-usama-tls-ecdhe-mlkem-update).

My understanding of both Google 2029 (more details in [0]) and 
Cloudflare 2029 is that publishing this draft does not appear to 
materially impact the 2029 timeline. Please correct me with supporting 
evidence if I am wrong.

Cloudflare 2029: According to [1], the deadline is to move to PQC in 
general, and not to pure ML-KEM key agreement. Much of the remaining 
work is on PQ authentication (see for example the timeline figure in 
[1]). Also see very recent (exactly one month) and enlightening 
presentation [2] by Bas for more details.

IMHO, to achieve these 2029 targets, it would be more productive to 
follow draft-barnes-tls-this-could-have-been-an-email, recommend hybrids 
and start focusing on PQ authentication.

On 07.04.26 22:35, Paul Wouters wrote:
> On Fri, 3 Apr 2026, Eric Rescorla wrote:
>
>> This is precisely what I said in the text above:
>>
>> That normally happens with RFC publication, but we find ourselves
>> in the difficult case where an algorithm *is* being worked on in the
>> IETF but there is real contention about whether it should be 
>> published [0],
>> leaving us in an unfortunate situation.
>
> The contention is whether it should be published now or later, when
> classic protections gain us little to no benefit.

FWIW: With couple dozen folks opposing publication with substantial 
concerns, "publish now" seems premature at this stage.

IMHO, recent repo activity also seems contrary to what folks have 
requested, so things don't seem to actually move towards "publish later".

>
> Google and Cloudflare just adjusted their deadlines on this from
> further into the future to 2029.
FWIW: As mentioned above, these deadlines seem irrelevant to this 
specific draft.
> It seems it would be prudent to have
> this algorithm as an RFC now, since we would want to have it ready for
> about 2029 anyway, if indeed classic algorithms would fall with a single
> vendor / academic budget. The way to say "we published an RFC to help
> people gain experience, but we don't want you to use this right now"
> is by RECOMMENDED=N.
>
> The other layers in the stack, eg IEEE, sits far closer to implementing
> things in hardware. 

I believe the same accelerator that is to be designed for ML-KEM in 
hybrid can be used for pure ML-KEM. So it would be helpful to better 
understand how publishing this specific draft would help the hardware 
vendors.

>
> People spend a lot of energy on the "but what if mlkem turns out to be
> broken", but lets remember that even without this document becoming an
> RFC, if mlkem turns out to be broken in 5 years, and a quantum 
> computer is
> easilly available, there will be about 5 years of stored data that can
> already be decrypted.

This reasoning seems to rely on two assumptions:

 1. ML-KEM is broken AND
 2. CRQC is available

If #1 holds, standardization of this draft will not help mitigate the 
resulting risk; pretty much the reverse.

If #1 does not hold, hybrids already provide a way.

> That is, we've already commited to mlkem being
> safe, and the extra seatbelt isn't doing much now and won't do anything
> at all, in just a few years.

FWIW: A more genuine concern should be that the *only* recommended 
algorithms by the TLS WG are classical.

>
> On the other hand, if mlkem is not broken, and quantum computers are
> available, this document makes the most sense to deploy.
>
> It makes 100% sense to get this document published as an RFC with
> RECOMMENDED=N. It solves the problems of the people who want to use
> it, and solves the problem of the people who don't want to use it.
I can hardly digest that until hybrid is published with RECOMMENDED=Y.
> And
> the TLS WG can go back to regular work again. Or we can keep discussing
> this every three months until another organization or goverment will
> stand up their own IANA style crypto registry and make the IETF
> irrelevant.

I absolutely won't worry even a tiny bit if that happens because I am 
pretty confident that the expertise -- all the way from protocol 
designers to implementers to researchers to formal analysts to 
cryptographers -- we have in the TLS WG are absolutely unmatchable. Even 
if some other organization will stand up, the world will really see a 
clear distinction between the quality of attestation of the IETF and 
that other organization.

Sincerely,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/yvRIXNJefxX39-bthiqFUE1bNwQ/

[1] https://blog.cloudflare.com/post-quantum-roadmap/

[2] https://westerbaan.name/~bas/rwpqc2026/bas.pdf