I made an error, the hybrid SupportedGroups are also Recommended=N in IANA; there has only been discussion of promoting them to Recommended=Y
On Fri, Feb 20, 2026, 9:26 PM Deirdre Connolly <[email protected]> wrote: > 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]
