I am concerned about not deploying any quantum-resistant key agreement, while also acknowledging that hybrid doesn't necessarily work for everyone, nor does non-hybrid. In this document we already register these options as Recommended=N, vs the hybrid schemes as Recommended=Y.
On Fri, Feb 20, 2026, 8:51 PM Izzy Grosof <[email protected]> wrote: > 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]> >> 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]
