To clarify, saying either hybrid or non-hybrid key agreement should not be deployed until a CRQC has been demonstrated fails to address the primary passive attack against TLS key agreement, and applies to both hybrid and non-hybrid— basically saying non-hybrid should not be deployed until it is too late
On Fri, Feb 20, 2026, 4:15 PM Nadim Kobeissi <[email protected]> wrote: > Wait, wasn’t the whole point of adding a PQ primitive to mitigate SNDL? > > Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only key > agreement is the only scheme that’s vulnerable to SNDL as far as I'm aware. > Please correct me if I’m wrong. > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > > On 20 Feb 2026, at 10:13 PM, Deirdre Connolly <[email protected]> > wrote: > > > 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]
