IETF Logo Mail Archive

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

Robert Relyea <rrelyea@redhat.com> Mon, 23 February 2026 23:25 UTC

Return-Path: <rrelyea@redhat.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 89334BC92711 for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 15:25:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 RyjKOGsot0v9 for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 15:25:15 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 C9928BC90B00 for <tls@ietf.org>; Mon, 23 Feb 2026 15:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771888515; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NeUjzgBMYdog5MuWYbRpAnmK/eyJYlSB9Ys2q3WcLLE=; b=MJsWxPijO6XtUMaEDKiQVJN61Gjx480pxz3m7H3VRUZIRvQpPS+qktG44zQsIPA/9oAsSu NcVFeFpGtV0+dy0NmlF2OqMdgVwRfmBW54HBJh+ubMfqEKrhi+E+bvqsuckcWqc4HSkNPj aVjTIcgRae088tEpnWyrKIh069+xlpg=
Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-440-BRxGXl8cM22SRFBlx6FBvQ-1; Mon, 23 Feb 2026 18:15:14 -0500
X-MC-Unique: BRxGXl8cM22SRFBlx6FBvQ-1
X-Mimecast-MFC-AGG-ID: BRxGXl8cM22SRFBlx6FBvQ_1771888513
Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8cb3b6b37d8so4155637985a.3 for <tls@ietf.org>; Mon, 23 Feb 2026 15:15:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771888513; x=1772493313; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NeUjzgBMYdog5MuWYbRpAnmK/eyJYlSB9Ys2q3WcLLE=; b=DsDI8TufKAhCJoS/lsOOfSMXP+IIBZL+VQ2wuY43+kJXSBC8ugKFygifeXbrFt3qhW AlZdeEx4xJ72ZEbFzdYO2xbz5CPJoFyGkZIUAQpRqb130t9HkMDqLczA/5MEpBKoPv8/ YX03aiHH0LS6YxebWG7FNlmsAiEtb7J86B3Bc7PzVTgYO9ykqJPfXplQIbl51AcMDMCX cC7fTVFWBsCILzKUV4uIi7ppMnI7EU5osUIuMuZViTeFJcZLD7nyf1Lp1IBSeXZqkkPM W2GFzAWR28JNNZeSz7fSJSE/rcZyXkeTWnGX2PpqGt8iRswk/vb5x5Yxtn0qnfwtHoPn aQ1Q==
X-Gm-Message-State: AOJu0Yxve4/tIivfjupbWkEPUB7s0Tau/6TQV7y8WDbocVqHgMWdM+dz 7oyqutgWbGVah+/ZaX/vG3ki9lDQkWwhOACcBno5/yaqsQ0vpjUjWTLgv9J1GuVlE8Z6lvRk2KZ 289D9zveF8AnLCG5lpwwxmsVt4vldW4STbVF29lImCx2zueFxs6fONceyOCTo2ZAyBvcLDmWcG+ 8Mc7XPmqD+ETpoK3NeXNVs6dzXeLc=
X-Gm-Gg: AZuq6aJDCwXCpk3NX47wPEr2S3n717hv6zwvylIMxdi/TP+0TW6ZxFsXrHuqT6uUC0j ryS/TEE0zcU+1fyckDCWvHL6Ifr73zRmue4JM9rsDRsaSOP8f+LiQ5eN6/dJoN3oh7IAVRV6pb7 rT1Lw1rKJjtlG3ss9tm+/Hh0qblzigVLxZiSuJzapTPVXNxRWtw0kSps3yJqVqXktTtkOwfGBVd wJoFj7pZ4X5GTm+qctKpny0Cdbrh7KagT7cvqk5KQrVWQyPUKcJcmbnVzsfX9XvkTZF5wmRGKBh gvYcn2lryEgWLte/2HcEiU1VTUDBU1KXgcKOnlyjyDjpHi3O8GpNgfZ+I6hLtvUoiIxqoZDOvC7 bSEhzBQgOmGfqsWSFpfwC3J7qvMa9uvcNX3jdLtap46bUuEfLuZ2Onenn15w=
X-Received: by 2002:a05:620a:45ab:b0:8c7:fdc:e84f with SMTP id af79cd13be357-8cb8c9e63a6mr1210566285a.11.1771888513440; Mon, 23 Feb 2026 15:15:13 -0800 (PST)
X-Received: by 2002:a05:620a:45ab:b0:8c7:fdc:e84f with SMTP id af79cd13be357-8cb8c9e63a6mr1210560885a.11.1771888512881; Mon, 23 Feb 2026 15:15:12 -0800 (PST)
Received: from [192.168.1.172] (c-24-23-245-90.hsd1.ca.comcast.net. [24.23.245.90]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cb8d0e7875sm862040385a.26.2026.02.23.15.15.11 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Feb 2026 15:15:12 -0800 (PST)
Message-ID: <850d1216-8b24-45e3-95ef-3a6899deaf73@redhat.com>
Date: Mon, 23 Feb 2026 15:15:11 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <MN2PR17MB40310F0A2891942D76C43E60CD6BA@MN2PR17MB4031.namprd17.prod.outlook.com> <2caab265-00ba-4078-b6d0-3a178dabaa61@tu-dresden.de> <CAEEbLAbkV4YxN7cgggckpEp24MLtRZpzs6M4KemBatpzCCcs0A@mail.gmail.com> <MEAPR01MB3654415F735DE96CEE239C78EE68A@MEAPR01MB3654.ausprd01.prod.outlook.com> <aZfbhrFDBp7a0xHL@chardros.imrryr.org> <EB48AB24-A1A2-47C8-9C2C-47C93B9320E7@thomwiggers.nl> <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com> <7e6727a1-c994-43df-a16b-078bd8995717@tu-dresden.de> <AS5PR07MB1059610AC3701494F1B0BE7A28968A@AS5PR07MB10596.eurprd07.prod.outlook.com> <CAFR824z7endo8REtKvxQp-0dbVuQvg532BFtT1UebPLOSKbS6g@mail.gmail.com> <aZkMpTWxJGsmx--C@chardros.imrryr.org>
From: Robert Relyea <rrelyea@redhat.com>
In-Reply-To: <aZkMpTWxJGsmx--C@chardros.imrryr.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: dajblTLCZHl8y2msAGdNu5lmYtju5iY23VwgV-HxZVQ_1771888513
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: 6ZUDDG2CBZ4JUD7BX7UOCMFZHEMLVPOL
X-Message-ID-Hash: 6ZUDDG2CBZ4JUD7BX7UOCMFZHEMLVPOL
X-MailFrom: rrelyea@redhat.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-07 (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/72ko-p-ngj-ja6EPzZFpm_jUUU0>
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 2/20/26 5:38 PM, Viktor Dukhovni wrote:
> I support publication as a stable reference for the already allocated
> code point that sports multiple implementations.

I support publication as well, for exactly Vikor's reason.

There is some feeling that publication == endorsement. Almost all the 
arguments against is 'hybrid is better, so it should be preferred'. I 
agree that is the case. I also know that I have customers that, despite 
our recommendations will want to 'pure' ML-KEM.

The fact is the exact same thing will be carried out independent of this 
acceptance:

We (and other libraries) will end up implementing this draft (whether it 
is published or not), and making 'pure' ML-KEM default off and require 
work to turn it on. We now (and will continue) to default to hybrid 
x25519mlkem as our preferred algorithm (and have since before that draft 
was approved).

Publishing the draft simple means "If you must do this, this is how".

>
> At least for OpenSSL, I don't expect publication to shift the needle
> from "implemented" to "enabled by default" (in clients and servers).
> The pure ML-KEM groups are not included in the default supported groups
> list and there are no plans to change that.  For a pure ML-KEM group to
> be used as the source of the key agreement shared secret it needs to be
> explicitly enabled on **both** ends and preferred by whichever side's
> preference order is taken into account by the server.
>
> Meanwhile, the X25519MLKEM768 hybrid has been enabled by default for
> almost a year, and will surely continue to be far more common in
> practice.
>

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