Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
From: Deirdre Connolly <[email-masked]>
To: Izzy Grosof <[email-masked]>
Cc: Nadim Kobeissi <[email-masked]>, "[email-masked]" <[email-masked]>, Rich Salz <rsalz=[email-masked]>, Paul Wouters <paul=[email-masked]>
Date: Fri, 20 Feb 2026 21:26:43 -0500
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

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-masked]>
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-masked]> 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-masked]>
> 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-masked]>
>> 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-masked]>
>> 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-masked]
>>> To unsubscribe send an email to [email-masked]
>>>
>>
>>