[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlk em-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 <bkaduk=
[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]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]