IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

Deirdre Connolly <durumcrustulum@gmail.com> Sat, 21 February 2026 02:26 UTC

Return-Path: <neried7@gmail.com>
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 <tls@mail2.ietf.org>; 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 <tls@mail2.ietf.org>; 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 <tls@ietf.org>; Fri, 20 Feb 2026 18:26:54 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-503347dea84so26635891cf.3 for <tls@ietf.org>; 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: <MWHPR05MB3647B28767462F896A389FF59D68A@MWHPR05MB3647.namprd05.prod.outlook.com> <CAFR824z0CBKSi8P1o2Nr-h0pueNNN_SNitUVSg+W2VaB36JJHQ@mail.gmail.com> <642EFEE3-E4B2-43E4-ACDD-C662F385769E@symbolic.software> <CAFR824xGzq7DHHU0xAhTeLBSG2mJvCFWSbhKbYk5fMrSwF4tsw@mail.gmail.com> <b650b79c-59d3-47d6-9ef6-09dfc24e8550@email.android.com>
In-Reply-To: <b650b79c-59d3-47d6-9ef6-09dfc24e8550@email.android.com>
From: Deirdre Connolly <durumcrustulum@gmail.com>
Date: Fri, 20 Feb 2026 21:26:43 -0500
X-Gm-Features: AaiRm50ZzAKIBpn4b9lgbJetajfORupNkgToFobLfqrTajL8PRu_3SkjwAmm358
Message-ID: <CAFR824z6BV+E_MoZ33O3zWw3G8MYukrXY_pJ9uu4k1Tr33kXxA@mail.gmail.com>
To: Izzy Grosof <izzy.grosof@northwestern.edu>
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 <nadim@symbolic.software>, "TLS@ietf.org" <tls@ietf.org>, Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>, Paul Wouters <paul=40nohats.ca@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rjQksfq8dCuPGG57cX_n8OSBbtI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@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 <izzy.grosof@northwestern.edu>
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 <durumcrustulum@gmail.com> 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 <nadim@symbolic.software>
> 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 <durumcrustulum@gmail.com>
>> 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 <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
>>> 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 -- tls@ietf.org
>>> To unsubscribe send an email to tls-leave@ietf.org
>>>
>>
>>

v2.39.1 | Report a Bug | By Email | System Status