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

Paul Wouters <paul@nohats.ca> Wed, 08 July 2026 15:16 UTC

Return-Path: <paul@nohats.ca>
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 D6F9611310B12 for <tls@mail2.ietf.org>; Wed, 8 Jul 2026 08:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783523785; bh=0mLq+A53h7+S1gb0nYS2hiFq58S7Igot0nSna3EJzgM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=a5jrb1ik4ls3BFZTbf+l5rPSqgfmmXt7V4vaIXXhpM6DeDoPfk+hqJkh+RwogvriD 7+7rEvXytfWjj6IDrqphafBNu1/m3va4ctOOMhne84Yc3oYcKU7bQjL52khCYxSRhn pcilwtZB0uYwNhBPfF6hCiiUKkbrWBqaY2KxGEok=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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_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 (1024-bit key) header.d=nohats.ca
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 dxmpCYr3hMWs for <tls@mail2.ietf.org>; Wed, 8 Jul 2026 08:16:25 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7B00C11310B0D for <tls@ietf.org>; Wed, 8 Jul 2026 08:16:25 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4gwMBH3bq5z2DP; Wed, 8 Jul 2026 17:16:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1783523783; bh=5AwcTDtgH6tdrpDHgPBiAHTMlXQnTQGXznY8bc6QtMM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p9hLjHmJKVe9LIKz1WzZaPsaLTJ4DBmPDG7KFeNjIeBOkt/N/wbVJi9+h3Xbmjor/ bWnwozFxIoYXSS8mf1XGa+MZtX/qurc9CbpWmKyUJt10KYwVV6UZl4RIk3sUxXxBDB pDSn97mzeAdhw/Ip47DnSOUsY/Zpn1X8shcHsiFc=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pYPSqQJ6wicq; Wed, 8 Jul 2026 17:16:22 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 8 Jul 2026 17:16:22 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 55E83191F8B9; Wed, 08 Jul 2026 11:16:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 524F6191F8B8; Wed, 08 Jul 2026 11:16:21 -0400 (EDT)
Date: Wed, 08 Jul 2026 11:16:21 -0400
From: Paul Wouters <paul@nohats.ca>
To: gessel@blackrosetech.com
In-Reply-To: <9b7bf3ea-9743-4a7a-aea9-7d336476254d@blackrosetech.com>
Message-ID: <f2c5885c-9cdf-b788-d921-765e70b042a4@nohats.ca>
References: <9b7bf3ea-9743-4a7a-aea9-7d336476254d@blackrosetech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: ROEKZY2DGYJ3KM4P3VVRGO4O5KLRKLX7
X-Message-ID-Hash: ROEKZY2DGYJ3KM4P3VVRGO4O5KLRKLX7
X-MailFrom: paul@nohats.ca
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
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/0ISYLNFMrhUC9mWou9DNXc0lTf0>
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>

On Wed, 8 Jul 2026, David Gessel wrote:

>  I do not support publication of draft-ietf-tls-mlkem-08 in its current form.
> 
> My objection rests on uncontested text in FIPS 203 itself. Appendix C.1 (third bullet) documents that the round-3 Kyber step m <- H(m)
> was removed from ML-KEM.Encaps, and states the rationale plainly:
>
>       "The purpose of this step was to safeguard against the use of flawed randomness generation processes. As this standard
>       requires the use of NIST-approved randomness generation, this step is unnecessary and is not performed in ML-KEM."

For those people with this argument, why didn't you also oppose draft-ietf-tls-ecdhe-mlkem that has the same issue?

> Should the WG proceed despite these objections, the Security Considerations should at minimum (a) state explicitly that ML-KEM's
> security argument assumes randomness of approved-RBG quality, (b) cite FIPS 203 Appendix C.1 so implementers understand the m-hash
> removal and its stated precondition, and (c) reaffirm hybrid key agreement as the recommended deployment.

Are you then also in favour of pulling draft-ietf-tls-ecdhe-mlkem which
has the same issue you raise?

I am confused about the arguments against MLKEM as the algorithm itself,
as the discussions on the mlkem hybrid had no issue with the mlkem
parts.

Also, if you think mlkem is unsafe as PQ algorithm, which alternative
would you propose? How would we reach consensus without rerunning a
NISTlike algorithm competition. And run it quickly to defend against
"store now, decrypt later" ? And why would this be a TLS WG effort,
instead of building on actual consensus of cryptographers?

That is to say, I think selectively applying this argument to
draft-ietf-tls-mlkem but not draft-ietf-tls-ecdhe-mlkem is invalid.

Paul