IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

Richard Barnes <rlb@ipv.sx> Tue, 07 July 2026 21:43 UTC

Return-Path: <rlb@ipv.sx>
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 5668711271F27 for <tls@mail2.ietf.org>; Tue, 7 Jul 2026 14:43:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783460617; bh=PY+DyP8gYVRte/7BXoZe/118eRRKHNFPGr21drt06RE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=jv5x3hq6ykrm6PhEknNyyiaoddyW+E4+t8pl7xrli71/e6V8PdHhwgMVLOtOlIzae LgSV0lS7V2iFQt2fBu5ioHfh26NjeXhExi/39IjkgXOOGtDNokGqO1oL3mznVaCqMy TcxqtP4HvT7tk+jdPUCPqhUD9TDT8p0KQc3Rx0PY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20251104.gappssmtp.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 rV2ZgJHzU9PZ for <tls@mail2.ietf.org>; Tue, 7 Jul 2026 14:43:35 -0700 (PDT)
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (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 4C5FE11271F1B for <tls@ietf.org>; Tue, 7 Jul 2026 14:43:35 -0700 (PDT)
Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-44cd990a94dso21061fac.1 for <tls@ietf.org>; Tue, 07 Jul 2026 14:43:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783460614; cv=none; d=google.com; s=arc-20260327; b=IPT87CioDg09IZfaFTk42XRUQzky144iuGT+bgTUIkLjQk3LGATw3lpg/D7YUNRYag 3leeChujr25WpeXldLVWz1gYEu7eGqTXZzuhYgm6FTwjhd2lYbAkiO257Gej/mOKlgMY hWMon/STZqOJqHI6Uyl579qlGD7S/boRnqaG0vdaK6gsHcLr5wEfgGbpqXM2UjgXZYS4 otftHNaOh9HX8ykUt0MQvBJivQgD3DDlHzd5126UvCDIRrp1vL6LRZHY0i/Y1og4lNbk HtYo1O4edzRutKC96rNUQl2hJSc1004JqRg6K6Os9im2FPAAgQTt/pamLW0SmZeTDtBR 1fMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=YAeV8rjlBhfp0kZcCre2WH2AJeHCwvpRu1bMfOVDcaA=; fh=YHwdOGhWxI7GO9HRc4cLmebFtA2To5rYLfo4GOyIfRU=; b=YOAICwD4gQstaoYysy3+WCfbTXQOj2ZZeINYZEAeo3Wjq3r0M9mar8VMMspUUN/D6v E6GUj//wv7sQWsklved02tlC9p+opQpl5xLu9FCWoIYAymdFmW3ABT9zuFWhb6Wt0Xd1 OcH7odaf5JoxgfKJkj/3PR7askkf3ieg6pbZmZ+yP2hfJqoeE++omVDzPSMJOqURP030 4vSOag+8Vy+lzsXT1Kt8SXz6taM8yMy5NBOahaa/OQo1iDbCvk2HRcpi+KWKdcVS3RNg o3fkX/i9UtJ4raIC+yJ00GIGptlDGB+/+0IWfOXoq26h4afmvQRkEf/aHBpsikHZ/PWy s61g==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20251104.gappssmtp.com; s=20251104; t=1783460614; x=1784065414; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=YAeV8rjlBhfp0kZcCre2WH2AJeHCwvpRu1bMfOVDcaA=; b=t7iTF3XTkJDBXe2fCZSKOpg3W2zi6i/mncub2TpD4/fjlia8r8m/w8OyKxJ9PDNTY9 X7I/UnPemCRgUt7nn3GeM4MZ8atttnWBkRiiXNEnhM94uQ/4cYC9UdXKQB0K0F/Qx5gL YGNW0tj6niwdaa4IMi0nP5UA9w63Jcr2SvQHjjJ2vjI+jJxmBcVjVLXozjQfxf/0Zuzd E3ed5wqkBlNaJ/0ANNZmyYI7a7is7kxAUdjV9J2F8IICPcnMJUryOBQY+OEwT511tAw+ lo85nnwRaau2qqdANzlPHjYiAEbNFLVs0TV+4z3LIAFGLqpSZf92pGZXAw9ewFAW4ESW uLcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783460614; x=1784065414; h=content-type: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:content-type; bh=YAeV8rjlBhfp0kZcCre2WH2AJeHCwvpRu1bMfOVDcaA=; b=msZI++cfkIUJQqq3927y3aJCm9bIywrP4AngEBss/BY9l2YB4EYtSAXq7N2GN4t29b I3eetw4JwqZVXaD4vpD9FKm2RL5REyeGPqqkuu9NTtnMxYXAQlR+2fcisi17bJ96T9xc fal3Hq9cpdMmONIR+aWJditmiIVauhbxSNkvssSFFfMsEeBi1JiMVD3ReKFwCZ1nTLIg un6YF7sYhiLHmZbQTDYqqptu/cp42O30aeS6kCU5R4DVUsAOCljsTt3wlzM1or7qd7B8 K+z7YZe0WuSSgkGqod2lS+m2av+gmvyQhYdiK05c8SPhTS1cX+SdirdG3xQFYxseCCQX KjkQ==
X-Forwarded-Encrypted: i=1; AFNElJ80hVS6Jxe5VtEUcRzc5PckVD2UekSrCuTZXxM2FNldZnmLWlSA/mmWeymPvoDQy7GQl14=@ietf.org
X-Gm-Message-State: AOJu0YzSuYjM+h7RFHJVwiiDJwh9HPzDxz4FnkfTtlpC5brpIkHPLdk3 EeKiPlOjI+/kR71cGx0gmURBvAvFZsbopHI7lTph3rUfFNXa1xAAIltRO6zW//hDNB/7SjdyAf4 QkaQ9cKvxFBw0iqC8kiDhCH2bHldQlxRJeY/AYuAR1w==
X-Gm-Gg: AfdE7cm+mEbem/DGQB5dubIx4djEOPocbhNqP+UsH6TPdBv8W/n6P3b6ET2oNZybe+4 Dlr1bx1E/3TtaXEf9eAd3wJgC0+1BSJBCqt4GPVjON/e8Z+GGxKe5bIPsYsHfFKTN8G8Q6cd6yX JPkuMCZbRdAD98XB0hMB4BoHM/LMTO78yIxnwYA4gmsIl4XF6t1Plp/sJMR6W6lxq50Kvw4u013 jnoMnHTvk74Nmls42mYHNixoup1GpkuJxtUAxCwAVKXYFVZl4cUlEoXvz5n1sbHlhgBYOtC
X-Received: by 2002:a05:6870:8893:b0:448:952a:d3c8 with SMTP id 586e51a60fabf-4510618a813mr4423694fac.12.1783460614454; Tue, 07 Jul 2026 14:43:34 -0700 (PDT)
MIME-Version: 1.0
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 07 Jul 2026 11:43:23 -1000
X-Gm-Features: AVVi8CdA-0be6T3t0XiJIBDMkr2te12AKDtoTUEX76Mxpl2ZXuBrg2bYHPz3f1c
Message-ID: <CAL02cgRXFsq=y0QgQFVTyM0Ehrb1TDiMoM76=BM3bsWS1JO=sA@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="000000000000654d0a06560c483f"
Message-ID-Hash: QYHLXKZPE2X7JVDBQOGEBGXGJFSWN24G
X-Message-ID-Hash: QYHLXKZPE2X7JVDBQOGEBGXGJFSWN24G
X-MailFrom: rlb@ipv.sx
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: draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
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/82XsgvlPsmu-hzjL2LG9N9k9jns>
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>

Hi TLS folks,

Just publish this draft already.  The arguments have been hashed over a
thousand times and they are all FUD.  They present no reason to prevent
consenting systems from interoperating on this algorithm.

We need defense in depth! -- Why is this the one time in history that this
is the case?  We didn’t do RSA-ECC hybrids during that transition.

What if governments try to coerce people into using it? -- An RFC isn’t
going to make any difference, there are already public specs.

What if ML-KEM implementations have bugs? -- What if ECDH implementations
have bugs?  Look at the age of Linux vulns coming out these days, age is no
guarantee of quality.

This whole thing is honestly childish, like people can’t imagine that
someone might make a different choice than they would.  The point of having
negotiation in TLS is that different instances can make different
decisions.  Reasonable people can disagree on whether bare ML-KEM is OK,
and that’s all right.

Just publish it already.  Don’t let the IETF be held hostage by trolls.

—RLB


On Wed, Jun 24, 2026 at 5:00 AM Joseph Salowey via Datatracker <
noreply@ietf.org> wrote:

> This message initiates a new Working Group Last Call for
> draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key establishment
> for TLS 1.3. The main question before the working group is: "Should the
> working group publish a document specifying stand alone ML-KEM?". If there
> is rough consensus then we will push to refine and publish the document;
> otherwise, we will stop discussing the draft and not progress it. Please
> respond to this call indicating whether you support publishing a document
> specifying a stand alone ML-KEM. Please refrain from further discussion on
> this topic as most arguments have been discussed multiple times.
>
> Why are we holding this consensus call now?
>
> Significant developments have occurred both within this document and in
> the broader TLS ecosystem to address the concerns raised in the last WGLC.
> Therefore, the third consensus call is warranted. We ask the working group
> to consider document publication in light of these recent changes:
>
> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate
> consensus call, the WG agreed to promote the X25519MLKEM768 hybrid group to
> Recommended: Y in the IANA registry. Consequently, the IANA registry will
> reflect a clear community preference for a hybrid because Recommended: Y
> clearly indicates this while the standalone ML-KEM groups defined in this
> draft remain Recommended: N. The updated security considerations in [1]
> reference the IANA registry to emphasize this preference.
>
> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recently
> reached consensus to explicitly prohibit key share reuse across connections
> in TLS 1.3. The new text changes the guidance from SHOULD NOT to a strict
> MUST NOT. This resolves the concerns regarding static key reuse and its
> associated privacy and forward-secrecy risks for ML-KEM.
>
> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid
> KEM groups in TLS 1.3. This supports other results which show that KEMs are
> secure when used in TLS 1.3 and that hybrid groups are secure even if one
> of the components is compromised.
>
> - Liaisons: We received liaison statements from multiple SDOs including
> O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing support for the
> publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to
> provide a stable normative reference.
>
> Please note that a third-party IPR disclosure exists [5] against this
> document regarding patents related to the underlying ML-KEM algorithm. This
> IPR declaration has not changed since the last WGLC. As a reminder, per BCP
> 79, the IETF takes no stance on the validity of patent claims, and the
> working group may decide to proceed with a technology despite IPR
> disclosures if it decides that such use is warranted.
>
> Conduct Reminder: Given the heated nature of previous discussions on this
> topic, participants are strongly reminded to adhere to the IETF Code of
> Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback
> professional, technical, and focused on the document's text.
>
> This working group last call will end on 2026-07-08.
>
> Joe and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> [2] https://datatracker.ietf.org/liaison/2198/
> [3] https://datatracker.ietf.org/liaison/2151/
> [4] https://datatracker.ietf.org/liaison/2148/
> [5]
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

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