IETF Logo Mail Archive

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

Joshua <joshua@marionberry.net> Fri, 13 February 2026 00:33 UTC

Return-Path: <joshua@marionberry.net>
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 A99A5B69C66A for <tls@mail2.ietf.org>; Thu, 12 Feb 2026 16:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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=marionberry.net
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 FtVkHUXSZfYU for <tls@mail2.ietf.org>; Thu, 12 Feb 2026 16:33:26 -0800 (PST)
Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch [185.70.43.17]) (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 8298AB69C64A for <tls@ietf.org>; Thu, 12 Feb 2026 16:33:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marionberry.net; s=protonmail; t=1770942798; x=1771201998; bh=qrEmBhQBpkOywj74VtsQE4iYXOYTHZMsP2qnyG1C7AM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=LLDF99SkUjVXJEzM8Byx4tpr1PrvmExbRjbN+PeNvE62ZritO2uq/c54BiAsDd3ma PspyjrtoVGqNJotbS704JlJuRi1FdsF3z5Vad9h24rFL/PAvaXd4LZkgGEphn4BUKK RV0W02sKBwnyeaLk5fm3/zw+s973npzc3CB/kJP3iHTDi9DdptKMaKA/bhraJc1uS1 Gw379eRYO7i4MohoyFHM+QbDu9LvTEyrcCDLxOmb9ADnetrZmVfwqSd+1wJjlB/vB8 66Xbz7cLFuMbHaPTxWGd3xujLrC4hI0Ni66yhwD5kZhIgutRTbHZu5m2UKPWZc3Kk8 6NQVMpdW64Iwg==
Date: Fri, 13 Feb 2026 00:33:12 +0000
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
From: Joshua <joshua@marionberry.net>
Message-ID: <0frFX5BZ7eVntMY7eXCo6axRtf6bU5Kf55pcI175oQ1I6UDuWd5ofwjQNMw86ZpQvHl2tPBRh6RXf5kMEvjIoLj9QnmPzDW0KfysWc8vXU8=@marionberry.net>
In-Reply-To: <MN2PR17MB403154CDEF3945F2A89A01EFCD60A@MN2PR17MB4031.namprd17.prod.outlook.com>
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com> <AS5PR07MB10596FC9D182E975AA0E11F8E8960A@AS5PR07MB10596.eurprd07.prod.outlook.com> <1050A0B9-9F8D-4762-BAF6-1BD290249F90@vigilsec.com> <CAFR824wWeM-0XYYc2XbLHBZFwCUZY4G-uoPTt6X0H23QgNcpUQ@mail.gmail.com> <DS0PR15MB5674C55563A2FA4A0ADE7FC2B360A@DS0PR15MB5674.namprd15.prod.outlook.com> <CH8PR21MB5484936F98431369D1099C588C60A@CH8PR21MB5484.namprd21.prod.outlook.com> <MN2PR17MB403154CDEF3945F2A89A01EFCD60A@MN2PR17MB4031.namprd17.prod.outlook.com>
Feedback-ID: 131523398:user:proton
X-Pm-Message-ID: b30af38449ad3d59ca4a72297651b86f40c63564
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------0442874d3c962885f1bceeb790de4784facae23b90142e6a62e4ee09f10d4928"; charset="utf-8"
Message-ID-Hash: BKJBBWWXZ2PAQNJMYTFPPXFRK4MHXWMX
X-Message-ID-Hash: BKJBBWWXZ2PAQNJMYTFPPXFRK4MHXWMX
X-MailFrom: joshua@marionberry.net
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: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>, Ben Schwartz <bemasc=40meta.com@dmarc.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/1tMtzaqNqz2WP2QPGDcjJJY7kVE>
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 keep hearing this “there are communities that want pure PQ”, but I’ve yet to
hear a compelling reason for this that doesn’t involve embedded devices where
code size is a constraint (mentioned in passing in the latest draft). If we’re
going back to the days of ‘customer knows best’ in regards to deciding which
ciphersuites are secure, then Camellia and ARIA ought to come back, and Simon,
Speck, and ChaCha8 ought to be introduced.

While I respect the contents of the draft as probably secure, I think we need to
acknowledge the duplication and unnecessary risk we are introducing alongside
the universally respected hybrid suites. Is there a customer that can provide a
compelling reason as to why a hybrid construction degrades the security of their
product? Is there any compelling reason at all against hybridization?

Andrei states:

> Private sector SW vendors need to comply with government rulemaking, at least
if they hope to sell products and services to the government. Also, certain
private sector organizations tend to adopt government guidelines for their own
operations.

If the TLS WG standardized every government guideline in order to enable private
sector vendors, then there would be far too much noise. McEliece, HQC, SLH-DSA,
LMS, FrodoKEM, NTRU… The purpose of TLS 1.3 is to choose a small selection of
the most conservative ciphersuites for long-term confidentiality. Introducing
standalone ML-KEM alongside the currently deployed hybrids goes against that
principle.

Additionally, I’d like to point out a compelling case against adopting NIST
requirements without further scrutiny: Dual-EC-DRBG. Anyone with a pair of eyes
could see that the lack of truncation and the use of constant curve points
rather than a Hash-To-Curve algorithm (or even hashing to a point, as is the
case with NIST curves) indicated that someone knew the discrete logarithm of P
to Q. It could only have been implemented by Microsoft, RSA, Cisco, and other
large companies because there was no scrutiny. I find it particularly
disheartening to see—once again—a lack of scrutiny towards the selection of
secure defaults for worldwide adoption.

I do not support publication of this document.

Best,
Josh.

-------- Original Message --------
On Thursday, 02/12/26 at 14:47 Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
wrote:

> The draft has “Recommended N.”  There are communities that want pure-PQ, even
> if this WG thinks it’s not the best thing to do.
> 
> I support publication.

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