IETF Logo Mail Archive

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

Simon Josefsson <simon@josefsson.org> Wed, 24 June 2026 15:38 UTC

Return-Path: <simon@josefsson.org>
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 66A641068E1E5; Wed, 24 Jun 2026 08:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782315483; bh=mgQEj7UhEAe1vPMAgxFpxcTGTiAURW5ccqTuK9n/7MU=; h=From:To:Subject:In-Reply-To:References:Date; b=xQsc4/fiUazweqx75PMjjA3IBZlajqVPVMl9jrLU+kvaxI7uyh9DIcYGO7pxdFm2U EYdi3UJ2mksVxKrupyy0+Wau0eANmfW28WHWInHk7MQwYRHT7bwPGKSSwd8hEjQ3ma dEv8XU3Ez17x/bSVlzisuEt8rQ9zMVVwN6HDOJX4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 2.269
X-Spam-Level: **
X-Spam-Status: No, score=2.269 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_PBL=3.335, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="qgTPHmJa"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="Uiin+pZ6"
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 0_7SWFxsYLCa; Wed, 24 Jun 2026 08:38:00 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A87561068E0A9; Wed, 24 Jun 2026 08:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mgQEj7UhEAe1vPMAgxFpxcTGTiAURW5ccqTuK9n/7MU=; t=1782315425; x=1783525025; b=qgTPHmJafY9zOtI3Iek45OQDFz9Vhj1ywD5vbp08RwaWa3zAN4fAlrXqV3c4MeGDITSN92yLTwp o007Gy1hhDA==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mgQEj7UhEAe1vPMAgxFpxcTGTiAURW5ccqTuK9n/7MU=; t=1782315425; x=1783525025; b=Uiin+pZ6WA5rumsVq6nJe1XK8iB4oqoK0RpgsTDi2/WFbY0RjIhw1hMgLeLmAv2RhLnk0y1HzXO hMEer+CgGCBFUljJ4OxwzKCyXA1SgvONu6CxK/fP8KTsqq7Zer2auhnDT1x47vmrf5rn6bJ1srTAo VjupiN2Oo7yzHHZvqLwZuaCtf92aHO9SINTjApv3UwPTMPwpvM/OwLqJRV770iUaMSprGxK40CaFZ Lqe9Ug1G55ltscptOW3kgTeDxNlcF11crxoJBLqgRU1/65Ncamo22gg7QaEcVHSJvOIHpWAv4efnR 3klz8uLi1QSUPjoluvSie7+GVcINwJiNyL/M2rd8D8+4U+LE/D2H8NSM4bvpEfc0iH+08dsHBD5mo flKFb2vYdX680jcpyKexnCQ4dCTMhNKaz787gYKcEXhYPk4i2kVh5KAQyeQDBZHetZ9gcnrqG;
Received: from [2001:9b0:21d:2c00::437] (port=45902 helo=frallan) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1wcPer-002Gk3-GP; Wed, 24 Jun 2026 15:36:57 +0000
From: Simon Josefsson <simon@josefsson.org>
To: draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org, Joseph Salowey <joe@salowey.net>
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> (Joseph Salowey via Datatracker's message of "Wed, 24 Jun 2026 08:00:07 -0700")
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:260624:tls-chairs@ietf.org::MAO5+zR0vI1UsaCD:5/sQ
X-Hashcash: 1:23:260624:joe@salowey.net::PSY2JeqAZ81NSQWJ:TF16
X-Hashcash: 1:23:260624:noreply@ietf.org::H24I0Ad5j5EhGY8i:02GAZ
X-Hashcash: 1:23:260624:tls@ietf.org::s3cNkfuBbybx0VE1:0bjhJ
X-Hashcash: 1:23:260624:draft-ietf-tls-mlkem@ietf.org::R0Y1qs6zdn2i8ORk:1c6n8
Date: Wed, 24 Jun 2026 17:36:58 +0200
Message-ID: <87o6h054rp.fsf@josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Message-ID-Hash: VDQVJTIX4LIIAWIXO2ABP5F5VBQPRTNT
X-Message-ID-Hash: VDQVJTIX4LIIAWIXO2ABP5F5VBQPRTNT
X-MailFrom: simon@josefsson.org
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
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/SABh7Sw1dqdv_I04WFUeQByoVVY>
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>

All,

I am against publication of the document through the TLS WG.

My reasons were explained earlier, e.g. in [1], and have not been
addressed in later versions of the document.

If this document is published (e.g., through the ISE or AD-sponsored,
which seems more appropriate for political crypto), consider adding
warnings about the risks of using non-hybrids and lattices.

/Simon

[1] https://www.mail-archive.com/tls@ietf.org/msg23297.html

Joseph Salowey via Datatracker <noreply@ietf.org> writes:

> 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