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

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

I’d like to put on record my 100% agreement with Daniel Apon’s points.


--
V/R,
Uri


From: Daniel Apon <[e-mail]>
Date: Sunday, April 5, 2026 at 20:17
To: Peter Gutmann <pgut001=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [EXT] [TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"


This Message Is From an External Sender
This message came from outside the Laboratory.



Hi Peter,

I remember, and enjoyed, your talk slides about an abacus and a dog. Scribble is adorable.
It was not, as you claim for whatever reason, a breakthrough in that paper to provide a ZKP for their claim of a smaller reversible ECC-addition circuit; such techniques have been proposed many times before. (I don't particularly think it was especially useful to provide a ZKP attesting to knowledge of a smaller reversible ECC-addition circuit, but oh well. One can go verify the semantics of their NP language, their ZKP software, and their ZK proof, etc., if you like.)
Also, I suppose "the middle distance" is Google's 2029 deadline now.


Let me turn to a more important point (or, points) by Usama in this thread:

"IMHO, unless some technical rationale is provided by IEEE 802.11, this LS should just be read as 'someone somewhere in the world would like to use pure ML-KEM' and TLS WG should not serve as a printing press for such requests."

I completely disagree with the characterization that 'someone somewhere in the world would like to use pure ML-KEM.' It's dismissive of the current situation.
Not only has the international community, after more than a decade of work, aligned on ML-KEM as the PQ-KEM standard, but IEEE (as a computer scientist, IEEE is not no one!) is requesting that the TLS WG "please stop delaying."


Even further up the thread, Usama writes:

"I was actually hoping to see some technical rationale for support of publication."

May I please point you to
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf <72400682-baaf-4ea3-9f7a-42ad8b99b89f>
or
https://csrc.nist.gov/Projects/post-quantum-cryptography/email-list <0e13dc6f-55b0-4d6c-bdd0-d5bcaa953f60>
for overwhelmingly sufficient technical rationale?


If the international consensus on ML-KEM as the post-quantum KEM standard is insufficient, would you please explain further what you explicitly desire in terms of technical rationale?


Kind regards,
--Daniel


On Sun, Apr 5, 2026 at 10:24 AM Peter Gutmann <pgut001=[e-mail] <f0b7ecbc-5feb-4c94-a883-31ee1eb5fd0c>> wrote:
Viktor Dukhovni <[e-mail] <593ad9d6-2a0b-42a2-92c7-02e3023a8793>> writes:

>Recent theoretical progress on reducing the resource requirements (logical
>qbits, and circuit sizes, i.e. gate counts and time) for breaking 256-bit ECC
>with Shor's algorithm, may have reduced the perceived value of the ECC
>components of hybrids for some QC "optimists" who were betting on CRQC's to
>show up in O(decade), but now think it may much sooner than previously
>expected.

It's yet another paper, following 25 years of well-established precedent, that
begins with the authors gazing into the middle distance and saying "assuming
we have a functioning magic device" and then constructing some elaborate
framework based on this imaginary device. Except that in this case they're
not even telling us what the framework for the imaginary device is. There's a
page or two of vague generalising about what they can do towards the start,
and the remainder of the 57-page paper is telling us how terrible things will
be if the magic works.

We can't even get someone to perform the same astounding feat of mathematics
as a barking dog or an abacus yet because no-one knows what's been discovered.
The real breakthrough in the paper seems to be the elaborate means they've
come up with to hide what they've actually done.

So I'm not losing any sleep over it.

Peter.
_______________________________________________
TLS mailing list -- [e-mail] <67174b66-c159-4110-82f2-9d1ee370f51c>
To unsubscribe send an email to [e-mail] <00478633-1b85-464d-a75d-7cf5d3228de9>