To clarify, are you concerned about a scenario in which someone is willing to deploy either classical-only or ML-KEM-only, but is unwilling to deploy the hybrid-ML-KEM system, and so with a recommendation against ML-KEM-only prior to a CRQC demonstration and towards hybrid-ML-KEM, instead chooses classical-only, becoming open to Save Now Decrypt Later?
In this scenario, this provider is already refusing to deploy the best option prior to a CRQC demonstration, namely hybrid-ML-KEM. Should we not attempt to convince this provider to support hybrid-ML-KEM via this clarifying text, rather than omit a clear indication of the best course of action? As a compromise, the clarifying line that I'm suggesting could say something like: "Non-hybrid ML-KEM should not be deployed prior to the public demonstration of a security break of the classical component of hybrid ML-KEM via a quantum computer. However, this is not a reason to prefer classical pre-quantum cryptosystems over non-hybrid ML-KEM: hybrid ML-KEM should be used instead." A line like this addresses the scenario that you're describing, I believe, by removing any perceived advantage to classical-only. On Feb 20, 2026 15:21, Deirdre Connolly <[email protected]> wrote: 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<https://urldefense.com/v3/__https://symbolic.software__;!!Dq0X2DkFhyF93HkjWTBQKhk!Uf4nfZhJqaAjKdsbw9YrmYmf_PjTf8RbqF1-wL30JtJS4yPBcMTdGrbkuCGM8wdYpPUun72UFFN8hQdYAGpEyJGB6n5R_VmrhT4$> On 20 Feb 2026, at 10:13 PM, Deirdre Connolly <[email protected]<mailto:[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]
