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

John Mattsson <[email protected]>
Newsgroups gmane.ietf.tls
Message-ID <AS4PR07MB8825D93033943C45EA0AC47189FE2@AS4PR07MB8825.eurprd07.prod.outlook.com>
I think it is often overlooked that the probability of someone building a CRQC is not independent of the progress of the PQC migration. A rapid migration to post-quantum key exchange and signatures significantly reduce the incentive for any government to build a CRQC. The probability that industry would develop a CRQC on the same timeline is lower.

We should also distinguish between different probabilities. We need to migrate if there is even a small probability that a CRQC will exist in the not-too-distant future. That is entirely compatible with believing that the most likely outcome is that CRQCs will never be built.

Cheers,
John Preuß Mattsson

From: Daniel Apon <[email protected]>
Date: Thursday, 9 July 2026 at 05:25
To: Benjamin Kaduk <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

"I don't feel like a CRQC will ever eventually exist" doesn't seem like a position that would convince, in recent memory, any of e.g. U.S. government, the French government, or - say - Google (maybe we should ask people if they're connecting to the Internet broadly via Google Chrome, which holds ~69% (nice) share of the global browser market by my napkin math).

On Wed, Jul 8, 2026 at 11:12 PM Benjamin Kaduk <[email protected]<mailto:[email protected]>> wrote:
On Wed, Jul 08, 2026 at 11:27:26PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
>    Of course, that’s obvious. However, this has nothing to do with the point
>    I’ve been making — and which, apparently, keeps falling on a deaf ear:
>    If ML-KEM does fail — does not matter why (bad ML-KEM design, all lattices
>    get broken, only Modules, etc.) — whatever sensitive data is protected by
>    ML-KEM today or in the near future, will fail with ML-KEM.
>    TL;DR: if your data needs to outlive CRQC, ECC does not help.
>    > I have strong reasons to believe you are wrong . . .
>    In what?
>    Please explain which one(s) of the above statement(s) is(are) wrong.

"whatever sensitive data is protected by ML-KEM today or in the near future,
will fail with ML-KEM" is only true in a world when a CRQC ever exists, and is
trivially wrong otherwise.  Your TL;DR includes that factor but the preceding
statement does not.

It's clear that you are confident that a CRQC will eventually exist, but based
solely on public data that is not guaranteed.  And while what counts as
"sensitive data" for you may need to remain confidential for decades, that is
not true for everyone's sensitive data; if the relevant timeframe is just a few
years after which loss of confidentiality is not a big deal, then the tradeoffs
and cost/benefit analysis can easily reach a different conclusion.

-Ben

_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.