IETF Logo Mail Archive

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

Toerless Eckert <tte@cs.fau.de> Mon, 23 February 2026 00:48 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3F6B8BBDB20B for <tls@mail2.ietf.org>; Sun, 22 Feb 2026 16:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cs.fau.de
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 oCsXantzGfYA for <tls@mail2.ietf.org>; Sun, 22 Feb 2026 16:48:24 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (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 2BB73BBDB1FB for <tls@ietf.org>; Sun, 22 Feb 2026 16:48:23 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4fK2Jt31Tpz1RCCY; Mon, 23 Feb 2026 01:48:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.fau.de; s=r20250630-faui40; t=1771807696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SMDgSi1DfzPWBqsrXvX4d1m9OpBuoOKTLA8AWRmXHmo=; b=mWDSjyxjseEUNm0h6zlo9MGO/6DE3YSMlQn5yftqLG0kU5Zvas2s4/gOEq9s8KtOLehnRT QveXqMY+KVG178h2q/NZkm1vwzUs648Gg+Wver2WA3EFWQHmyqgzE8qy1BncFqXIuC2jNM VHfY/9skdnKZbZxQV8KsrPWtkgGbY/p1ECd9pn9MnF1aUIlEu/EwrIUlsAFs2fkBYQcwi0 k9bjcRQP9W0ZwOIkt+Cr/56zZATpD/pmVxa72Drw/E71VOIMW/cGv5NPFu0RAuwhPY76bi DyXAGZ/ZhYDomfOZIkXdf9Y4w/xElF11yAuu0m5I1X8KHsmJnH+GZ7nHRBqZvw==
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4fK2Jt29ttzl38n; Mon, 23 Feb 2026 01:48:14 +0100 (CET)
Date: Mon, 23 Feb 2026 01:48:14 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Joseph Salowey <joe@salowey.net>
Message-ID: <aZujzgcgPu0CHDRB@faui48e.informatik.uni-erlangen.de>
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
Message-ID-Hash: K25FO5ABZ5AAUMOBW2OHXRCT3XE5YYS4
X-Message-ID-Hash: K25FO5ABZ5AAUMOBW2OHXRCT3XE5YYS4
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
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: "<tls@ietf.org>" <tls@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/nKo0pO7R3zJr-sjUyNdvIB1FKas>
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>

Given how i am only 

  a) a beneficiary of TLS (thanks for all the privacy fish so far)
  b) A non-cryptography-expert reader of draft-ietf-tls-mlkem-05
  c) A spectator usually attending this type of TLS debates with popcorn

I hope my comments are useful, and although i definitely will not call myself
a TLS WG participant, i do not think it would make sense for me to raise the points
later in IETF last call than now during WG work phase (more work for IESG).

I will constrain myself to two asks for textual improvements that i would like to see.
Especially because without such textual improvements i wouldn't even
be able to come up with a good laymens opinion whether or not, or rather when
and where to apply this drafts technology (as opposed to the alternative).

1. I think this document needs a BIG BOLD FACE introductory warning. something like

THIS RFC DOES NOT SPECIFY AN IETF STANDARDS TRACK METHOD. IT IS SOLELEY 
PUBLISHED FOR INFORMATIONAL PURPOSES. THE IETF RECOMMENDS TO USE 
draft-ietf-tls-ecdhe-mlkem IN ALL CIRCUMSTANCES INSTEAD OF THIS DOCUMENTS METHOD.

If this text is too strong, then maybe the WG should try to find a text
softened sufficiently for maybe even more than rough consensus. But the document
really needs an explicit reminder about the difference in status because
it is likely that people will browse through this draft who are just pointed
to it as a reference in some "regulatory framework". Even worse: It may be
browsed by people rewieving such a regulatory framework, not understanding
that from the eyes of the IETF there is a better technology. So let's pleae
make sure we (IETF) are not so lame to think that it is sufficient to
direct user of our technologies to our preferred methods by just the document
header (heck, i just had IESG reviews that totally fell apart because IESG
didn't even check the status of RFCs correctly).

2. Given how important TLS and the evolution towards post-quantum crypto
is for many industries, it is quite frankly irresponsible to publish documents
whose only real-world discussing text is

  a) Intro text: "standalone post-quantum key establishment, targeting smaller key
     sizes or less computation, and simplicity"

  b) One page of "only-for-the-eyes-of-security-experts" Section 5 
     (security considerations)

I really think that as long as this stays a WG document instead of an 
individual submission, there needs to be a much more "laymen" oriented
description of attack vectors and how draft-ietf-tls-ecdhe-mlkem vs
this draft will fare against them. A good amount of this was discussed
on the list, but none of it made it into the text. That is lazy 
by the WG.

Of course, such an "operationally" focussed discussion of security
properties comparing the two mechanisms would also work very nicely
as a separate RFC, but i wouldn't know how IETF could make sure that
this RFC does not get published until such a comparison is also published
(normative references in an informational RFC ?).

At minimum, it would be lovely to have at least ONE example in the RFC, how the
added amount of storage and compute for ECDHE in the hybrid solution is
significant, given how (in my laymen understanding), both storage and compute
would predominatly be determined by MLKEM. Else the intro claim "targeting smaller key
sizes or less computation" is just marketing that should be removed. 

Or to paraphrase Uncle Ben:

 With great power over crypto comes great responsibility to explain better.

Cheers
    Toerless

On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote:
> This message starts the second Working Group Last Call for the pure ML-KEM
> document (draft-ietf-tls-mlkem-07).
> 
> 
> The file can be retrieved from:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> 
> The diff with the previous WGLC draft (-05) is here:
> 
> 
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>
> 
> 
> The main focus of this WGLC is to review new text providing more context
> around the use of pure ML-KEM.  For those who indicated they wanted this
> text, please let us know if the new text satisfies you and if you support
> publication. This working group last call will end on February 27, 2026.
> 
> 
> Thank You.

-- 
---
tte@cs.fau.de

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