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: =?utf-8?q?=5BTLS=5D_Re=3A_forwarding_draft-ietf-tls-mlkem-05_use_case?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/C178GqFpiUOUYrHkfZK1vQ2xkmk>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------9870c6d8abebdafe5e94c351f2c345cbb968964fc5825cd370891fdf70726fcf
Content-Type: multipart/mixed;
	boundary="189518ee388f7518_c1b2a28ccb63f03a_4b7438efa2304bd2"


--189518ee388f7518_c1b2a28ccb63f03a_4b7438efa2304bd2
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I completely agree with Viktor=E2=80=99s statement. While I don=E2=80=99t un=
derstand the protocols supporting high frequency trading, I find the claim t=
hat HFT is bound by the handshake time dubious. I also wasn=E2=80=99t able t=
o support the claim that HFT traders even use TLS at all; my understanding i=
s that HFT traders use private connections that don=E2=80=99t have any encry=
ption, 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.=20

It just doesn=E2=80=99t make sense to sell a high-frequency product where a =
TLS session must be opened before every trade, as that would also imply logg=
ing on/validating authentication before every trade, which would add extra l=
atency as well. Any product that does this wouldn=E2=80=99t be competitive c=
ompared to other providers that optimize for latency.

I=E2=80=99d love to hear more from this trader because, as always, I could b=
e wrong. But it seems to me like there is no aspect of high frequency tradin=
g where logon/session establishment latency is critical.

Best,
Joshua Nabors              =20
                              =20

-------- 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.  =F0=9F=87=BA=F0=9F=87=A6 =D0=A1=D0=BB=D0=B0=D0=B2=D0=B0 =D0=A3=
=D0=BA=D1=80=D0=B0=D1=97=D0=BD=D1=96!

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org

--189518ee388f7518_c1b2a28ccb63f03a_4b7438efa2304bd2--

--------9870c6d8abebdafe5e94c351f2c345cbb968964fc5825cd370891fdf70726fcf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmmUpb8JEEi7HaL9cnidRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmcfoZpGhaN3WLWlyJuDpPu83SVnihm7Omgj/Vnr
/sNlEBYhBCFVaVef6Xfhxy2qnEi7HaL9cnidAAAx9AD+PXQRNEntnj2y8W0X
7/YswEP1Y8Ito38CnUWH1YM41hgBAIGSUdX1OzBhIFVcLDaW8zqYUbiLOI4U
fQTCG1k4VkYH
=SXJN
-----END PGP SIGNATURE-----


--------9870c6d8abebdafe5e94c351f2c345cbb968964fc5825cd370891fdf70726fcf--