[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

[Deirdre Connolly <[e-mail]>]

> non-hybrid ML-KEM should not be deployed in a user-facing manner until a
CRQC has been publicly demonstrated.

This fails to mitigate Store Now Decrypt Later attacks which are considered
a live threat to present TLS traffic, whether using hybrid or non-hybrid PQ
key agreement

On Fri, Feb 20, 2026, 4:04 PM Izzy Grosof <[e-mail]>
wrote:

> > This seems like a tremendous waste of time. The chairs should exclude
> from
> their consensus determination mail from people who are not limiting their
> comments to clarifying text and are instead relitigating the same
> previously discussed arguments. There is no reason to believe the same
> people going off topic now, will not simply go off topic on yet another
> WGLC.
>
> To offer a substantive comment on topic, focused on clarifying the text of
> the proposal, it seems that the two main use cases for non-hybrid ML-KEM
> are either to plan ahead for the future development of a CRQC, or to deploy
> once a CRQC has been developed, and there is agreement that CRQCs do not
> currently exist.
>
> I therefore propose to add a line to the document which states that
> non-hybrid ML-KEM should not be deployed in a user-facing manner until a
> CRQC has been publicly demonstrated. Concretely, non-hybrid ML-KEM should
> not be deployed in a user-facing manner until the classical component of
> the relevant hybrid cryptosystem (e.g. an elliptic curve cryptosystem) has
> been demonstrated to be broken (e.g. a concrete decryption demonstration)
> via a quantum computer.
>
> I believe this additional line would be amenable both to people who think
> that this demonstrated break of classical systems will come relatively
> soon, and so non-hybrid ML-KEM will soon be relevant, and people who think
> this break will not come for a while, and so hybrid ML-KEM will stay
> preferable for a long time. To be clear, this additional line clarifying
> the proposal does not block developers from creating non-hybrid ML-KEM
> software, but only recommends against deploying that software prematurely.
>
> My research area is the performance modeling of computing systems, so a
> stochastic model of future security degradation is natural to me, both of
> classical cryptosystems via quantum computer and of ML-KEM via classical
> attacks. Hybrid cryptosystems should be used until the times comes when it
> is sufficiently cheap/quick/easy to break classical cryptosystems via
> quantum attacks that no substantial security benefit is provided by
> including the hybrid component. There is a distribution of how long this
> will take, and different people will have different estimates of this
> distribution. I think it is relatively uncontroversial that there is a
> substantial probability that classical cryptography is not broken (or
> substantially degraded in security) for tens of years. We should provide
> guidance which clarifies our stance relative to this timeline.
>
> Finally, I want to point out that a wide variety of institutions have some
> expiry date on the duration for which they want their information to stay
> secret. For example, the US government has automatic declassification
> procedures after 25, 50, and 75 years. We should clarify the text of this
> document in a way that benefits readers interested in this form of
> limited-duration security in the 10-100 year time scale, by clarifying that
> non-hybrid ML-KEM should only be deployed to users after a demonstrated
> full decryption of the relevant classical cryptosystem.
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>