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

Joshua <joshua@marionberry.net> Tue, 17 February 2026 17:33 UTC

Date: Tue, 17 Feb 2026 17:31:05 +0000
To: tls@ietf.org
From: Joshua <joshua@marionberry.net>
Message-ID: <QoU2sZuraBPD8Ak_h7dueHinUBEXa-y2P0riVkyeZM7d1iwOMVjQHaEQB7BESm7fjDgKh2z9BSyC7gsxAKAsWz5ssi5UsGtZw8eJstR2IWQ=@marionberry.net>
In-Reply-To: <aZSjqJmagFIPRXWB@chardros.imrryr.org>
References: <350ec383-ae75-cadf-ab47-41811d5d9cec@nohats.ca> <aZSjqJmagFIPRXWB@chardros.imrryr.org>
Feedback-ID: 131523398:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------9870c6d8abebdafe5e94c351f2c345cbb968964fc5825cd370891fdf70726fcf"; charset="utf-8"
Message-ID-Hash: YZTBSU7P7E3K42LDJZVFCJ4QFQKYPPNV
Precedence: list
Subject: [TLS] Re: forwarding draft-ietf-tls-mlkem-05 use case
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/C178GqFpiUOUYrHkfZK1vQ2xkmk>

I completely agree with Viktor’s statement. While I don’t understand the protocols supporting high frequency trading, I find the claim that HFT is bound by the handshake time dubious. I also wasn’t able to support the claim that HFT traders even use TLS at all; my understanding is that HFT traders use private connections that don’t have any encryption, just raw TCP/IP. My understanding is that the vast majority of third-party service providers only perform a TLS handshake directly before logging on, and use a stream protocol like WebSockets for further messages. 

It just doesn’t make sense to sell a high-frequency product where a TLS session must be opened before every trade, as that would also imply logging on/validating authentication before every trade, which would add extra latency as well. Any product that does this wouldn’t be competitive compared to other providers that optimize for latency.

I’d love to hear more from this trader because, as always, I could be wrong. But it seems to me like there is no aspect of high frequency trading where logon/session establishment latency is critical.

Best,
Joshua Nabors               

-------- Original Message --------
On Tuesday, 02/17/26 at 09:22 Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Tue, Feb 17, 2026 at 11:02:08AM -0500, Paul Wouters wrote:

> 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.

This does not look to me like a compelling rationale.  A high-frequency
trading system that does not route trades over a connection that was
established well before market open, and expects to beat the competition
by minimising connection establishment latency, is perhaps doing it wrong.
For already established TLS connections latency does not depend on which
key agreement group was used in the initial handshake.

In environments where resumption is typically available, TLS 1.2 can
somtimes offer lower amortised connection latency than TLS 1.3, because
TLS 1.2 does not redo key agreement during resumption.  While in TLS 1.3
interoperably negotiating "psk_ke", rather than "psk_dhe_ke" can be
quite challenging.

One might also point out that the payload of high-frequency trades is
not likely to be a long-term secret.  Old news by market close, if not
in a matter of minutes or seconds.  So harvest-now decrypt-later does
not look like a significant threat model in this use-case.

Why not just negotiate X25519, the smaller Client Hello packet size
likely more than makes up for any speed advantage from ML-KEM-768,
and its performance is quite competitive: (on my low-end CPU):

                                  op/s
     253 bits ecdh (X25519)    33494.6
                             keygens/s  encaps/s  decaps/s
                 ML-KEM-512    54360.7   80885.2   53943.8
                 ML-KEM-768    36473.2   60446.3   39872.6

Since for ML-KEM a client will do both keygen and decapsulation, X25519
may well be faster all around with little apparent reason to rush into
either pure or hybrid PQ in this use-case.

--
    Viktor.  🇺🇦 Слава Україні!

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org

Attachment: signature.asc

[TLS] forwarding draft-ietf-tls-mlkem-05 use case Paul Wouters
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Viktor Dukhovni
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Bas Westerbaan
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Joshua
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Eric Rescorla
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Peter Gutmann
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … Muhammad Usama Sardar
[TLS] Re: forwarding draft-ietf-tls-mlkem-05 use … John Mattsson
[TLS] Re: [EXT] Re: forwarding draft-ietf-tls-mlk… Blumenthal, Uri - 0553 - MITLL

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

Attachment: signature.asc