IETF Logo Mail Archive

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

Antony Vennard <antony@vennard.ch> Mon, 29 June 2026 11:37 UTC

Return-Path: <antony@vennard.ch>
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 8D6AA109BBD34; Mon, 29 Jun 2026 04:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782733051; bh=eylV8eqaWkw1409SKMFo5Z+CC7S06FjnHcVHroyiv58=; h=Subject:From:To:Date:In-Reply-To:References; b=DWBnmvXI5h/J68kbc4XdyGoXBGqYI80ysCvicUTfz7q4kDLpTgLLHIthwX3sQvYSk zBiH0yndMbf5WViV9Ra0gbdjk8HOYNV/ag4uzvWTfBYCAGEwrtYBMva70UqNoSHhXi xSyQS37JVnuyIFrWNpXmomhfllcCRaYaDVJ3hews=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level:
X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (4096-bit key) header.d=vennard.ch
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 R85othxqMNUh; Mon, 29 Jun 2026 04:37:28 -0700 (PDT)
Received: from chameleon.vennard.ch (unknown [IPv6:2a03:2040:1:508::c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E03A6109BBC78; Mon, 29 Jun 2026 04:37:04 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by chameleon.vennard.ch (Postfix) with ESMTP id 5C271120068; Mon, 29 Jun 2026 12:36:42 +0100 (BST)
Received: from chameleon.vennard.ch ([IPv6:::1]) by localhost (chameleon.vennard.ch [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ORydGZjrOVyw; Mon, 29 Jun 2026 12:36:42 +0100 (BST)
Received: from localhost (localhost [IPv6:::1]) by chameleon.vennard.ch (Postfix) with ESMTP id 0400A120069; Mon, 29 Jun 2026 12:36:42 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 chameleon.vennard.ch 0400A120069
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vennard.ch; s=9ECFC226-3425-11E4-849C-FD7C69C5B08C; t=1782733002; bh=eylV8eqaWkw1409SKMFo5Z+CC7S06FjnHcVHroyiv58=; h=Message-ID:From:To:Date:MIME-Version; b=aq9Xt/F5TvfsqVRz3naJwLiqPludXQEeO5ncSiT382oO2we5UkMc3Qpwsr7zrqB2y Kdz/zIcNWADH5llz/YHcydXe5oR1z8/U+V3+zrYxcg6gvx0DgBvmgqK4AYTC50pjd2 fgaG9TnWSs2GwCW4O8WAr9wwvH3aAHTVCgCQNulRw/ysrY/00AVM/YxkYUMQIsjNeR dXFqJYliLzFDvPLbqdcVIUtM43KQjL0hPOn+fTCghx7hmvcbyofdVib0oNCBQP/ONH f3MLNS8ZP8R7Q23cK76kU3Z4N0lJHW8LEnW678lEVnKLTj/hMfs4ImcMXjBbTsaw8R 9dRee0lpWhlX8ZqGAaTQzXgV0N/F9PEJ6yNGEGkL+quJX8qBcB2kcBsq2Z9bneHBYy flaM1RhpuSB6JsZgHh3PhNlvnt3yliTle5BhvqD9st2ajBb6+ADVuV8mwPmcHEyQxt 7YaiYjf15pirOE+S3AQjCENSp/ld/EUXO19moiUm5AKA6Yd13TSHt4dRAr2ESkqDw4 G9UucKbZqvk0qrYBOGnPKQ6GKxH4gpbhDmgRFmEMe7Rcd23QW9HFk7V4sUTNORZ0Dg B6YI0ePIn2wbRyy/RNyy/h0c/O185fKo7US6JIB7rRYPZTY7bKcUospLk7nV+iWMaR XqFtJ/0dHofgYdjcBasn/Cb0=
X-Virus-Scanned: amavisd-new at vennard.ch
Received: from chameleon.vennard.ch ([IPv6:::1]) by localhost (chameleon.vennard.ch [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id WKpaxnQHdVhS; Mon, 29 Jun 2026 12:36:41 +0100 (BST)
Received: from [10.16.0.14] (22.237.193.178.dynamic.cust.swisscom.net [178.193.237.22]) by chameleon.vennard.ch (Postfix) with ESMTPSA id 19E45120067; Mon, 29 Jun 2026 12:36:39 +0100 (BST)
Authentication-Results: chameleon.vennard.ch; dkim=none
Message-ID: <2366159b6976368114c8c036bf379fa3e5795a6c.camel@vennard.ch>
From: Antony Vennard <antony@vennard.ch>
To: Joseph Salowey <joe@salowey.net>, draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org
Date: Mon, 29 Jun 2026 13:36:48 +0200
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.60.2 (3.60.2-1.fc44)
MIME-Version: 1.0
Message-ID-Hash: KVB2VWBTURJLVAOI4N4SMZM7I64IYRBU
X-Message-ID-Hash: KVB2VWBTURJLVAOI4N4SMZM7I64IYRBU
X-MailFrom: antony@vennard.ch
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/f_qaCjRna9XKkGYPYDyZhMKKTfo>
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>

Good morning,

I am a long time lurker but have never published to the list before (I
think), so feel free to adjust your opinion of my view accordingly.

I support publication of this document.

As a result of CNSA 2.0 preferring pure-PQ, a number of major libraries
have already implemented either all code points or some of them:

 - OpenSSL:
https://github.com/openssl/openssl/blob/e60d940b29504b7b1f15d1fe597ae9cdde701c8a/providers/common/capabilities.c#L181-L183
 - BoringSSL:
https://github.com/google/boringssl/blob/be08ef39e96191146b978ecbfd8eb8c3b50babb9/ssl/ssl_key_share.cc#L446
 - aws-lc and s2n-tls:
https://github.com/aws/aws-lc/blob/6283365b1d43abadfa9b997812cef06b095f7f04/ssl/ssl_key_share.cc#L682-L684
https://github.com/aws/s2n-tls/blob/e30701f7880eb5b87516eecc2d0fa2b79f014344/tls/s2n_kem.c#L66

I think that having tls-wg have oversight of the specification is
better than not, given implementation will likely happen. I believe
recommended=N is sufficient to say that hybrids are currently the
preferred choice.

That said, I do not believe the risk of ML-KEM (and ML-DSA) to be
severe: there is no known cryptanalysis currently exploiting rank >=2
module structure at these parameters that performs better than generic
lattice reduction. Module-LWE also has a (granted, an asymptotic)
worst-case-to-average-case reduction - something neither RSA nor ECDLP
had.

Kind regards,

Antony

On Wed, 2026-06-24 at 08:00 -0700, Joseph Salowey via Datatracker
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