> 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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
