Return-Path: X-Original-To: tls@mail2.ietf.org Delivered-To: tls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AA007BB03563 for ; Fri, 20 Feb 2026 18:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9scO4YMwgjB for ; Fri, 20 Feb 2026 18:26:56 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6A28FBB034BE for ; Fri, 20 Feb 2026 18:26:54 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-503347dea84so26635891cf.3 for ; Fri, 20 Feb 2026 18:26:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771640814; cv=none; d=google.com; s=arc-20240605; b=LDh7k4BwKodtwVrUpW7jYCu+dAg5js+DTtpO1Y06fpkYJVEXKtVPxAOt5+2S4lTCHO R+g1l3smJ1AjG6b1ci2P0IeXyy/jHi8JJt3+sk8hAGFFigr5QROjDXMHESCdjoeM3Z1S EhkvboaloHJjquM+mH/nnei6e/cOiuj/NSOTkLAZkmWRkhvPqhHlXV1utlKsVGFogJ6a l8ExP8HNpgi7TbrZF6KPZGZuM43BVGbpeX/AyirLxeXJAh5CIxjzgYmsaYw43B8GWtk9 u/zLCe70cidZzuq7m845dPQFut+fZu7MDrthza4kgCGNDeyhJO6j7Pt+WBMZW8mqKvms bf8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=fyuynImcyZ0cxurk/rXBEI8uOkAZWhzXJU2fAaGN2to=; fh=nc3c6Kss58Dq7k0fuivUMFoDGkE+bBblsZ92o6zVyZY=; b=loUOHM4Mw5KlW5581BM9biz1BzEaaX60EWjVqCYIdAFyOAKvE4e80DLxni27lfjvIc masVkuUicVfHUB04/9KhJ/IlfpY+5rIcT9DSW3u7oSuD1LCOXV04stLr8XPqyQIGuQTY fZF4G/TEWalU9GaxV+Z+kr8gFVFidFajX/QFnlns0XI0xEbmPqKQERqwIDTNDGa0N1uT HdFBa3cbK1PzJlY65at0JieTuZyH9VtLW6LQ9atZs4/nv6L65chA1kEJ/ojOQT+IiOts gIIOqpDvx719AF6sZl+92zsIStmsmO0H64Ge+ljti1kqI9aEVDLBJlu81NDsNF32vici 2V+Q==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771640814; x=1772245614; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fyuynImcyZ0cxurk/rXBEI8uOkAZWhzXJU2fAaGN2to=; b=ZENtt2cdIorYmsbp9Ol1CC2sEuiVyJuJkSJeg/PWi/TZgDDuyo5QwcFmXClgj21rUt /Sfde7PfqjHHvcbAXf1o68Jae2OEDWdE4U+7Ab4qUeopczzSO/FmNeoUOO+Nb/cuBv58 1dMUT/xHWkfxNK4E/bpa8WfpoOK1ALPQwQ+T3AS2A1xjioK1r9vc9MNcoUTbP0T1qCSG um5fah/wT7PfPYdjzj/uj6XAjitFCObfofZWoX17JnYCADylqNGbVB5CLFHwT3N5z250 vdWerFy6PmEWgSvutsJUoKREvbQZ0zdQMv1y/3Vw4d+y9eg+G52AH3tdupKifjbPSj8G /iGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771640814; x=1772245614; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fyuynImcyZ0cxurk/rXBEI8uOkAZWhzXJU2fAaGN2to=; b=cnMFWQlVA9GFf3YKN0HuhXcyhcm5zXKpo+6VQtkz17JoBeiUmGzZ59jHmuJ8mlLI8d 0i9kB5H2FN1zzrm02TtxwzOAdxCwjnFhuGNe5hVMW8Cs/3jIWE1nyo3KnAl3SZ9N84jr OAaIC0DFAwZCmy9Ju1vmUxsP399jlu9WVXJmDY3aU22ZEaMkIQESQRJoxHUwMmcQ7DCL lFzFNusNQYu//JgZBUYeRi9LGCNTq7krY23iV6juD/SyG0X0iU173UYasBHBGCsJp4lS f3jSKN7arIegY3BUU6aZBSMyuJL9On9hb5O2l/evYdzkOsqr97Cfa0FAHDqsXeBLDuWl ZbPA== X-Forwarded-Encrypted: i=1; AJvYcCXOMPQZXc1OiSUGYMZeqm6JOSKWplqdX4N1yHql99QKNrY+t6ghbUKhDME6H2AAPmVOqh4=@ietf.org X-Gm-Message-State: AOJu0YxZkDojtcnW74t0+VAE+kjI9gDKwocBVkO+75kMMc6nC3jiKT9P 7aZ1lyezSiJl1gGD0OO0CoBj8l6nFyp5awYXedT71ssc3ZT+61Pn+O3OY1QJ0Re3iYeL/MniwO0 pZPakoCh8zHQQXgsn8dwKTb0Pa+f91PM= X-Gm-Gg: AZuq6aIJ2oU0cxBTn5cp/vrCsCUJASZspnLVuMP0g5l+GDaIE1jsf1eZy89pW0iZOTJ EinjXHmHhg+nWg3dJJQ5kyqWR2jd0yxep5XbMpoBBSRk/B8lMmMn86FSp/TxS6U1/fU42I1EiUN WgpDgwlDsjhrt/9BPzBRyE9NRQEyopCxt+VlLvrGL0QeWK2C8vRSkEsMEdenrbPKX0YkgUOeOIq R+Xipifpbz/hMiVb/WFPLXRhp41zVmMeIdQQVe+JY6B8n9BFurBAi3K2kmaP23i65PMCscnqmRM wqD5vIJdWhOGehdBSMAN+RnYYfs9VQWRP6+YbMT90I4z/YIqZec= X-Received: by 2002:ac8:5794:0:b0:501:502b:8c6b with SMTP id d75a77b69052e-5070bba48b8mr28950801cf.9.1771640813594; Fri, 20 Feb 2026 18:26:53 -0800 (PST) MIME-Version: 1.0 References: <642EFEE3-E4B2-43E4-ACDD-C662F385769E@symbolic.software> In-Reply-To: From: Deirdre Connolly Date: Fri, 20 Feb 2026 21:26:43 -0500 X-Gm-Features: AaiRm50ZzAKIBpn4b9lgbJetajfORupNkgToFobLfqrTajL8PRu_3SkjwAmm358 Message-ID: To: Izzy Grosof Content-Type: multipart/alternative; boundary="0000000000005d2e74064b4c450d" Message-ID-Hash: GKYN7AKE5ITGUWG45V4LVKJIIGUBFPBD X-Message-ID-Hash: GKYN7AKE5ITGUWG45V4LVKJIIGUBFPBD X-MailFrom: neried7@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Nadim Kobeissi , "TLS@ietf.org" , Rich Salz , Paul Wouters X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-05_=28Ends_20?= =?utf-8?q?26-02-27=29?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000005d2e74064b4c450d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3DN, vs the hybrid schemes as Recommended=3DY. On Fri, Feb 20, 2026, 8:51=E2=80=AFPM Izzy Grosof wrote: > To clarify, are you concerned about a scenario in which someone is willin= g > to deploy either classical-only or ML-KEM-only, but is unwilling to deplo= y > the hybrid-ML-KEM system, and so with a recommendation against ML-KEM-onl= y > 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 o= f > 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 wrote: > To clarify, saying either hybrid or non-hybrid key agreement should not b= e > 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=E2=80=94 basically saying non-hybrid should not be deployed un= til it is > too late > > On Fri, Feb 20, 2026, 4:15=E2=80=AFPM Nadim Kobeissi > wrote: > >> Wait, wasn=E2=80=99t the whole point of adding a PQ primitive to mitigat= e SNDL? >> >> Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only key >> agreement is the only scheme that=E2=80=99s vulnerable to SNDL as far as= I'm aware. >> Please correct me if I=E2=80=99m wrong. >> >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software >> >> >> On 20 Feb 2026, at 10:13=E2=80=AFPM, Deirdre Connolly >> 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=E2=80=AFPM Izzy Grosof >> wrote: >> >>> > This seems like a tremendous waste of time. The chairs should exclude >>> from >>> their consensus determination mail from people who are not limiting the= ir >>> 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 de= ploy >>> once a CRQC has been developed, and there is agreement that CRQCs do no= t >>> 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 shou= ld >>> not be deployed in a user-facing manner until the classical component o= f >>> the relevant hybrid cryptosystem (e.g. an elliptic curve cryptosystem) = has >>> been demonstrated to be broken (e.g. a concrete decryption demonstratio= n) >>> 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 pe= ople >>> who think this break will not come for a while, and so hybrid ML-KEM wi= ll >>> stay preferable for a long time. To be clear, this additional line >>> clarifying the proposal does not block developers from creating non-hyb= rid >>> 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 classica= l >>> 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 thi= s >>> 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 provid= e >>> 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 declassificat= ion >>> procedures after 25, 50, and 75 years. We should clarify the text of th= is >>> 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 -- tls@ietf.org >>> To unsubscribe send an email to tls-leave@ietf.org >>> >> >> --0000000000005d2e74064b4c450d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am concerned about not deploying any quantum-resis= tant=C2=A0 key agreement, while also acknowledging that hybrid doesn't = necessarily work for everyone, nor does non-hybrid. In this document we alr= eady register these options as Recommended=3DN, vs the hybrid schemes as Re= commended=3DY.=C2=A0

On= Fri, Feb 20, 2026, 8:51=E2=80=AFPM Izzy Grosof <izzy.grosof@northwestern.edu> wrote:
To clarify, are you concerned about a scenario in which someone is wil= ling to deploy either classical-only or ML-KEM-only, but is unwilling to de= ploy 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 t= o Save Now Decrypt Later?

In this scenario, this provider is already refusing to de= ploy the best option prior to a CRQC demonstration, namely hybrid-ML-KEM. S= hould 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 suggest= ing could say something like:

"Non-hybrid ML-KEM should not be deployed prior to t= he public demonstration of a security break of the classical component of h= ybrid ML-KEM via a quantum computer. However, this is not a reason to prefe= r 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 d= escribing, I believe, by removing any perceived advantage to classical-only= .

On Feb 20, 2026 15:21, Deirdre Connolly <durumcrustulum@gmail.com> wrote:
To clarify, saying either hybrid or non-hybrid key agreem= ent should not be deployed until a CRQC has been demonstrated fails to addr= ess the primary passive attack against TLS key agreement, and applies to bo= th hybrid and non-hybrid=E2=80=94 basically saying non-hybrid should not be deployed until it is too late

On Fri, Feb 20, 2026, 4:15=E2=80=AFPM= Nadim Kobeissi <nadim@symbolic.software> wrote:
Wait, wasn=E2=80=99t the whole = point of adding a PQ primitive to mitigate SNDL?

Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only k= ey agreement is the only scheme that=E2=80=99s vulnerable to SNDL as far as= I'm aware. Please correct me if I=E2=80=99m wrong.

Nadim Kobeissi
Symbolic Software =E2=80=A2=C2=A0https://symbolic.softwar= e

On 20 Feb 2026, at 10:13=E2=80=AFPM, Deirdre Connolly <durumcrustulum@gmail.com> wrote:

>=C2=A0non-hybrid ML-KEM should not be deployed in a u= ser-facing manner until a CRQC has been publicly demonstrated.=C2=A0

This fails to mitigate Store Now Decrypt Later attacks wh= ich are considered a live threat to present TLS traffic, whether using hybr= id or non-hybrid PQ key agreement=C2=A0

On Fri, Feb 20, 2026, 4:04=E2=80=AFPM= Izzy Grosof <izzy.grosof@northwestern.edu> = 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 ar= e either to plan ahead for the future development of a CRQC, or to deploy o= nce 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-hyb= rid 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 dep= loyed in a user-facing manner until the classical component of the relevant hybrid cryptosystem (e.g. an ellip= tic 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 t= hat 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, th= is additional line clarifying the proposal does not block developers from c= reating non-hybrid ML-KEM software, but only recommends against deploying t= hat software prematurely.

My research area is the performance modeling of computing systems, so a sto= chastic model of future security degradation is natural to me, both of clas= sical cryptosystems via quantum computer and of ML-KEM via classical attack= s. Hybrid cryptosystems should be used until the times comes when it is sufficiently cheap/quick/easy to bre= ak classical cryptosystems via quantum attacks that no substantial security= benefit is provided by including the hybrid component. There is a distribu= tion 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 probabi= lity that classical cryptography is not broken (or substantially degraded i= n security) for tens of years. We should provide guidance which clarifies our stance relative to this timeli= ne.

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 s= ecret. For example, the US government has automatic declassification proced= ures 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 ti= me scale, by clarifying that non-hybrid ML-KEM should only be deployed to u= sers after a demonstrated full decryption of the relevant classical cryptosystem.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org

--0000000000005d2e74064b4c450d--