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] > <mailto:[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] <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]
