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 theIETF 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".
FWIW: As mentioned above, these deadlines seem irrelevant to this specific draft.Google and Cloudflare just adjusted their deadlines on this from further into the future to 2029.
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 implementingthings 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 anRFC, if mlkem turns out to be broken in 5 years, and a quantum computer iseasilly 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 availableIf #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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
