IETF Logo Mail Archive

[TLS] forwarding draft-ietf-tls-mlkem-05 use case

Paul Wouters <paul@nohats.ca> Tue, 17 February 2026 16:10 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 64627B8D2AB2 for <tls@mail2.ietf.org>; Tue, 17 Feb 2026 08:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 MOydfo1unCS7 for <tls@mail2.ietf.org>; Tue, 17 Feb 2026 08:10:13 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 9B58EB8D2551 for <tls@ietf.org>; Tue, 17 Feb 2026 08:02:18 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4fFktB6VdXzF23 for <tls@ietf.org>; Tue, 17 Feb 2026 17:02:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1771344130; bh=CP56FbndA0N88Ps1IUmZYvkYctQCQeV35+W1Doh7JQE=; h=Date:From:To:Subject; b=LQTaFxVMM7vRfoqk+2juDuyCWjtbj+fQ8gXZugUxTMVk3Oq1ZvmtC1LwD0cE0uSm/ 7GLc3ppOnF+liJ+tWHZ6UF+vJ4FMdZv6zyM3M1Mnfqk+mDR1AYNPvSfAtdm5/aJiEl 7+uwaYWvRFWOVGFO/v7bL/ydKtqcr3gOZA3vI22Q=
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 NqQ93h998VE2 for <tls@ietf.org>; Tue, 17 Feb 2026 17:02:09 +0100 (CET)
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 for <tls@ietf.org>; Tue, 17 Feb 2026 17:02:09 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6C6C018448FA; Tue, 17 Feb 2026 11:02:08 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 691A918448F9 for <tls@ietf.org>; Tue, 17 Feb 2026 11:02:08 -0500 (EST)
Date: Tue, 17 Feb 2026 11:02:08 -0500
From: Paul Wouters <paul@nohats.ca>
To: tls@ietf.org
Message-ID: <350ec383-ae75-cadf-ab47-41811d5d9cec@nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Message-ID-Hash: YTJZHYHO7IZMIYYZ3Z74UZLQ2IGH2UPX
X-Message-ID-Hash: YTJZHYHO7IZMIYYZ3Z74UZLQ2IGH2UPX
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] forwarding draft-ietf-tls-mlkem-05 use case
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/YZT5IzoumhTt3C53lQR2WOZNvBU>
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>

Hi,

I was asked by a TLS participant to relay some information publicly
regarding their pure PQ mlkem use case. I have rephrased their ontribution
in my own words below.

 	There is a use case for MLKEM in the market of high-frequency
 	trading.  Apparently there were complaints from those users (eg
 	traders) in the past about the performane impact of migrating
 	to TLS 1.2. If there is a performance drop with TLS 1.3 with an
 	MLKEM hybrid, then migration to PQ (or TLS 1.3) would stall. If
 	they can offer a (even tiny) performance gain of TLS 1.3 MLKEM
 	over TLS 1.2 ECDHE, then this individual would have a strong
 	case to deploy PQ security. Otherwise, the traders will insist
 	on waiting until a CRQC is publicly known to exist.

The individual stated they are in favour of adoption the pure mlkem
document along with the hybrid document so people can pick either,
depending in their use cases.

Paul

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