IETF Logo Mail Archive

[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

Russ Housley <housley@vigilsec.com> Mon, 06 April 2026 18:43 UTC

Return-Path: <housley@vigilsec.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 4D327D718F87 for <tls@mail2.ietf.org>; Mon, 6 Apr 2026 11:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775500985; bh=iKtc3iVQB8gHMD+1O18y5wx9TqUq3GmhEKq7XJSp4EI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=isrEZLT3IT5a3uCsEvIy/QN/QcUTAN0XPADBOLig8qsE/9acKl57G+rSvqI3m6Qsc a30m60Mq6ylAdTHVbOz4HvE+mMBCS4qCg0DJ55BaA+tQ8zNHCa4RKIJq9wGQ0o3Ff3 E8gLoYDr6KXrXQJl7qtdWRpjoDwjKx22V9l3p/7k=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_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=vigilsec.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 9Ua8tGO81eYY for <tls@mail2.ietf.org>; Mon, 6 Apr 2026 11:43:04 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 7BA0CD718F76 for <tls@ietf.org>; Mon, 6 Apr 2026 11:43:04 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 4C8091A149C; Mon, 6 Apr 2026 14:43:04 -0400 (EDT)
Received: from smtpclient.apple (pool-96-255-71-95.washdc.fios.verizon.net [96.255.71.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 376BD1A163D; Mon, 6 Apr 2026 14:43:04 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <903E494F-9C92-45C9-ADB2-96456A88AF91@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_23FEA866-4956-499C-8775-71B74B62FF06"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Date: Mon, 06 Apr 2026 14:42:54 -0400
In-Reply-To: <3d933b83-2b0a-40ac-80b9-dd2cc15b4766@tu-dresden.de>
To: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
References: <CAF8qwaBcotZqOnY2qJ6d0fRoa=5v0sZTOSWqeqkou+bLJcy9LA@mail.gmail.com> <CABcZeBPr+WeivTWpSCVC4f95fRuSiOytvvBPB_6r+af9Didhgw@mail.gmail.com> <CEB84168-5998-432A-9D62-36E28B9CDFA5@vigilsec.com> <CABcZeBM-eoqh+kJ7H6SiwC9p4tKAt+YiQhzetJZJmPNpXc+5OA@mail.gmail.com> <CAF8qwaALDXR6d=jLD46wXmKHDjyj=OdJ1X3a1AgxF+ByQceeMg@mail.gmail.com> <697d6134-0083-4933-8531-9be49118be7d@cs.tcd.ie> <adCCIZsvHqgci5LT@chardros.imrryr.org> <597455e4-29e1-46a0-a9a7-b87c5adbaec7@cs.tcd.ie> <adFBMGhVMOl2eptE@chardros.imrryr.org> <34c6c882-4cef-4350-9afa-0edb0b460eb6@cs.tcd.ie> <adHR1YEW-mPEb_BT@chardros.imrryr.org> <MEAPR01MB36540326A63FD5EAB70F652BEE5CA@MEAPR01MB3654.ausprd01.prod.outlook.com> <CAPxHsS+fv2S_Ydub24AHnFJUESxkr=h1me5NEtdsZ4bCqAip-Q@mail.gmail.com> <5b703cb2-721b-485c-963a-c6661b40c4c8@tu-dresden.de> <59ADD91D-9A81-4DC5-A3B5-3D8C2747AB96@vigilsec.com> <3d933b83-2b0a-40ac-80b9-dd2cc15b4766@tu-dresden.de>
X-Mailer: Apple Mail (2.3864.400.21)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vigilsec.com; h=from:message-id:content-type:mime-version:subject:date:in-reply-to:cc:to:references; s=pair-202402141609; bh=0UV+sPlJhtVz1wR9kVIjQCw/s01GQX7+qPDIULx8kDU=; b=gKQ83VO8eDpUdtYlIHy1Mxd++r4KT581PlQnqtfAbtsl1xoVhHMRJWfa0m2YqmXvrnc1yC+7nlOCT2Uf8JEnsPSxCdxR0Q209IGscRW1Te+DrDWW9/wDWnsj/PT/TOA6MWOmGC16FcZNQigV0I6toqUT0liZgUMw0/3Y6hqXpB+cLqGY3edc2T4KaBS6ULhBTV/nB+VBj/bt1byLPVvrZRXSG2AbSyi3my4GZkerOr7cb7LOsPL4P+e5qq57HivW0KklIhQhq5SR0OnOYlS2QNs0dAopOrucVMU9MF7hMnvPElgluRISRkd335Ic3A1h6kj84GDCbHRQSQTFz1V30w==
X-Scanned-By: mailmunge 3.09
Message-ID-Hash: WMPPZDLL6RGLDTRWLJYPJSKAM4JGIPT6
X-Message-ID-Hash: WMPPZDLL6RGLDTRWLJYPJSKAM4JGIPT6
X-MailFrom: housley@vigilsec.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: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"
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/4jeVb8OqJwafHWd-ja-FRS3QUQU>
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>

Usama:

>>> Soliciting an LS to "do the trick" for showing consensus does not address the technical concerns of two dozen people who have opposed publication in the WGLC. Given that there is no public evidence of IEEE 802.11bt having consensus on using pure ML-KEM in TLS protocol, isn't it fair to ask for technical rationale?
>> 
>> This response ignores a lot of context that has already been shared in this thread.  I am responding so that people that have not been following closely do not this your red text is correct.
>> 
>> IEEE 802.11bt is an approved project to add PQC to 802.11 wireless network standards, which already make use of EAP-TLS. The  Project Authorization Request (PAR) explicitly mentions ML-DSA, ML-KEM and SLH-DSA as examples of PQC algorithms.  The TLS WG has adopted draft-ietf-tls-mldsa, draft-ietf-tls-mlkem, and other algorithm-related I-Ds, which indicates to the rest of the world that PQC algorithm documents are in the works.  On the IETF/IEEE 802 coordination call prior to IETF 125, the was a heads up that the WGLC for draft-ietf-tls-mlkem was underway, but it might not achieve rough consensus.  The IEEE 802.11 WG sent a LS to indicate their desire foe the document.  Sending that LS required a formal vote, so your statement is absolutely incorrect.
>> 
>> You can find the approved Project Authorization Request (PAR) for 802.11bt here: https://mentor.ieee.org/802.11/dcn/25/11-25-0958-00-0PQC-draft-p802-11bt-par.pdf
> Thanks for the pointer. In my reading, this PDF only establishes their transition to PQC, which could very much be hybrids. At best, it seems to just have a quick mention of FIPS 203 in "Additional Explanatory Notes" and that could be used in hybrid fashion in TLS, no? Am I missing something?
> 
As I said, a formal vote was needed to send this LS.  That alone demonstrates consensus that they want pure ML-KEM as an option.  It does not mean that other options will not be supported.
> Regarding consensus: While the vote to send the LS confirms IEEE’s interest in the progress of the draft, does that vote specifically endorse an exclusive non-hybrid implementation in TLS? If there is a record (e.g., meeting recording, email thread) of technical rationale within 802.11 for preferring pure ML-KEM over hybrid, that would be very helpful for the WG to see, and maybe use in the draft for motivation.
> 
Nothing in their LS says anything about "exclusive".

You can find reports and minutes with your favorite search engine.  For example: https://www.ieee802.org/11/Reports/index.html

Russ

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