IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Sat, 21 February 2026 22:52 UTC

Return-Path: <ekr@rtfm.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 9303CBB6C933 for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 14:52:17 -0800 (PST)
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=rtfm-com.20230601.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 jpnN7SDGNMy4 for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 14:52:16 -0800 (PST)
Received: from mail-yx1-xb12a.google.com (mail-yx1-xb12a.google.com [IPv6:2607:f8b0:4864:20::b12a]) (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 9E349BB6C92C for <tls@ietf.org>; Sat, 21 Feb 2026 14:52:16 -0800 (PST)
Received: by mail-yx1-xb12a.google.com with SMTP id 956f58d0204a3-64ad019bb5eso2835430d50.1 for <tls@ietf.org>; Sat, 21 Feb 2026 14:52:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1771714336; cv=none; d=google.com; s=arc-20240605; b=ShUH0sW5XNyXiQ1PBUOu6Zo5klB1Ky9WvmEhQ5KTMkp9STkML+0YSdStuKeYMBTGXh s9ghSh4irWBCWx60MTLsvDledTjFSRpA/YA6oOL3cAc11tksU25xRrSgN8KWrfNO3hTN 88FnFKeqnMemOywd7GrESSVLvhqIWmncgUhTLkRY32xiZnDeekIwFohRuNsGR86bj9Jt 7Vz9MsuBzOSnxkto9X0XVdsX7OUkAoaaOuX4Oa1XKzLyv8KRCdIpxWXusxrhOICRkuhd LuBCvgxt0m9noJ9w99H+LWhJzXg7wBg6gvo6IJawIXzMm+2LbK8p40pNo8yCKYNJfvfc hnqQ==
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=Om3xpdNItXIWLuR7B69/rfcBe/4zbRy5lF9kXPSV4tk=; fh=F4oQci7cABEao36mAQIV6HMQunQxMGEyRmZ3xe0aelE=; b=c8ZZikqnZoI3pzJHSft+A8sM+mKMZchUbDL9UbO0QvyrLvO9NuMc+H0Y8jD0zKUKnJ kuLNoUcavtyEsLwcTcuUNk3hO5jbXm7ePiRhXpqjJXt/OiVnROlIXYlV5QhtzfeUragq iU5EkRbssOSadC3O93EZBvFbJdk6/7nP8LEwQXceBkVlJmQu44ImefVx6RrCGZ2BdlEB doLQCH8XEA7vBFwBGx+1lBzX31izbWSQRNJ9LRl3FWLCYjUrTW3hc3q6mywyu9eAqV09 ho34q+XSWzawlmmU+4iPt01UdyusX/bbQA/yMBhRUDk4q12wgFcNAjb3mKFqWWPfiQLC DAjw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1771714336; x=1772319136; 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=Om3xpdNItXIWLuR7B69/rfcBe/4zbRy5lF9kXPSV4tk=; b=qQ4g/khpyqacg0CrYeOoH8e6kDk2oZV/C38AEY/lxxbNztbPeAk5o+bKrvPNFXC69q O0Y8vkMVJeS00vZlA4vGoH+44Kf0wqeRco1yl/TlNnShLVFFpCpC9AtdxlhyNOpB26+G Zvk1RBn/o5Ag5Gf8IPbuG3WCtJ5xT7RAVLA+lX0sX7bppnLXhh9k/U/6FHPZiJSAT8H6 RrQF///9p51uGJxzMkKyZjtLgJhf+29+owcdAKqWxM4iGzCIggzJIKaiiDMtdeaVaekV 9yEb8bIRPa7Fgd1w6BhFA5035qBzTLVr5SWyqYXBSLEl2UPDMLV7KZcgCFI1xE82grYW n12g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771714336; x=1772319136; 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=Om3xpdNItXIWLuR7B69/rfcBe/4zbRy5lF9kXPSV4tk=; b=lW7TPUyxBfm75QtzFY+NGzw6iNeDSGxWVEDI+TD+qLCq4+D/qLE2WBchrOHUnc34Eu 0mZfWXPjpWRbKs8wJHtDfwsrKZGxSrEmjvz1WqSNwPYYCjT+C2rS9MeHxRDmYrB4LY+u rv4eJjmDJVE3P6tG3w0sGd5h+zThEzqU+qHj+m07Ea/d+6euB3GlYJPBdSapdWjGrAHr iC4uDF8cA2/g6EHamGDVsuguaU7YgsKfdr7M1zJmJAl4exKQJU+k102XvwrOBiU41kfN 66A9G03+sTqHQUUkbyyURGywqLjHYEsnU5lFaTSRHbKpLtNUHaBo7JYJvhv88CndOlUc Llvw==
X-Gm-Message-State: AOJu0Yw3+qXkTuGSkDKvXZ5b0wlCzDuTciNMbMgoa8P4EB+j2zFP7dv1 GN1M5cpC1kX4Mg8W3cSpJ3mGIrAWhzVLmBprq9aG1zOx2r6xDrVMY3Wk/ykhkbMPvBE0AXizYbd Fcy0LSFuGWSdpQwiEStZ2PCAkkHk8123m+jvryXEKRDHiviAyu2txVnZTgA==
X-Gm-Gg: AZuq6aKY9iMQhnsMv4cEKyZ4+0/4xXffOLrTGRmhPBGnOAccS7ObKiZ+3eEy/0eaZE7 8jtzwUQz9ZVo+jKloqyWVoaJOfGC+O40i0mitIuyqeqSWV0zohNFDYhQ6DRHtTPYyjLm7Y+Ij+C A6bo4mNWM9jW83FQ0KAX2elHhfO1tQNKJIOg7XuoZ4ML6EXolMxrlJcGDTP27Z5sWs6B285+W0z Cuc5uugzJ2OY8ER5B4PUYWtIIn9ovr6SNbNHS/23v+XtnauO+tS1Bz/jxOAMk4HiCN9p/pK7yDo msa0PKh15fZ8OLC76NbXllM5wq4AniInd6lcMKV7L9zheh78HoQMSXPWenfCl3xAiWLmMStTJUa AyanAlbSthwiBWEoWd2QWfQ==
X-Received: by 2002:a53:ee67:0:b0:648:f57b:d07c with SMTP id 956f58d0204a3-64c78d175a0mr2678854d50.50.1771714336024; Sat, 21 Feb 2026 14:52:16 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
In-Reply-To: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 21 Feb 2026 14:51:39 -0800
X-Gm-Features: AaiRm52aVJlIg5GH0LL_BqoCbuYieR04MQTuqw3EEl-KecShKR5R40FO8k7_r70
Message-ID: <CABcZeBM6sHJArV1FuWYbRA=XJtQiKKbmAeYt0YJuy4zAU2Ak7Q@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="000000000000a47cfa064b5d6307"
Message-ID-Hash: SJCNDW3XQU5BDCD55LNU3MUT6T365XQY
X-Message-ID-Hash: SJCNDW3XQU5BDCD55LNU3MUT6T365XQY
X-MailFrom: ekr@rtfm.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: "<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/F4de-UHY7XqQQSAqvR-X_4SG7BA>
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 mostly indifferent to whether this document is eventually published,
though sad that we're spending so much time debating it in the WG,
given the relatively minimal practical effect of publication. Specifically:

- The code points have already been registered
- This document is to be published as Innformational with Recommended=N.

It's not clear to me that the publication or non-publication of this
document will have much of an impact either way on the deployment of
this mechanism.


With that said, I believe that the current document has some issues
which need to be addressed if it is to be published

S 1.1.

   FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum
   [RFC9794] key establishment via a lattice-based key encapsulation
   mechanism (KEM).  This document defines key establishment options for
   TLS 1.3 that use solely post-quantum algorithms, without a hybrid
   construction that also includes a traditional cryptographic
   algorithm.  Use cases include regulatory frameworks that require
   standalone post-quantum key establishment, constrained environments
   where smaller key sizes or less computation are needed, and
   deployments where legacy middleboxes reject larger hybrid key shares.

I don't think this middlebox text is really on point.

If we look at John Schauman's helpful breakdown of a hybrid CH that
offers both X25519 and X25519/Kyber768, we see that the total CH is
1815 octets. Swapping out the hybrid for MLKEM-768 would buy you 23
octets, which doesn't change things materially. If we were to swap to
MLKEM-512, this would buy us another 384 octets, so assuming I'm doing
the math right, just that change gets us down to 1431 bytes, so it's
*just* possible that this might be large enough to push you into two
packets in some cases where the rest of the CH was appropriately
sized. I'm skeptical that this is going to be very frequent,
especially in light of the fact that at least the CNSA profile 2.0 [0]
requires ML-KEM 1024, which has a 1568 byte key, thus putting us
squarely in the zone of two packets with or without a hybrid.




[0] https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-02.html


S 4.2.
As a number of people have observed, much of this text repeats text in
8446 and contradicts the negotiation algorithm there, which depends on
the group list, not the key shares. You should remove everything up to the
graf that starts "For the client's share".


S 4.3.
Here too, the diagram seems duplicative, so I would remove it.

   The shared secret output from the ML-KEM Encaps and Decaps algorithms
   over the appropriate keypair and ciphertext results in the same
   shared secret shared_secret as its honest peer, which is inserted
   into the TLS 1.3 key schedule in place of the (EC)DHE shared secret,
   as shown in Figure 1.

I don't know what "honest" is doing here. If you connect to a malicious
peer, you might still get a shared secret.


S 5.2.

   While it is recommended that implementations avoid reuse of ML-KEM
   keypairs to ensure forward secrecy, implementations that do reuse
   MUST ensure that the number of reuses abides by bounds in [FIPS203]
   or subsequent security analyses of ML-KEM.

   Implementations MUST NOT reuse randomness in the generation of ML-KEM
   ciphertexts.

This kind of normative language doesn't belong in Security
Considerations.  If it's important it should go elsewhere.

-Ekr



[0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.png

On Thu, Feb 12, 2026 at 11:06 AM Joseph Salowey <joe@salowey.net> 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.
> _______________________________________________
> 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