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

Eric Rescorla <ekr@rtfm.com> Tue, 17 February 2026 18:08 UTC

MIME-Version: 1.0
References: <350ec383-ae75-cadf-ab47-41811d5d9cec@nohats.ca> <aZSjqJmagFIPRXWB@chardros.imrryr.org> <QoU2sZuraBPD8Ak_h7dueHinUBEXa-y2P0riVkyeZM7d1iwOMVjQHaEQB7BESm7fjDgKh2z9BSyC7gsxAKAsWz5ssi5UsGtZw8eJstR2IWQ=@marionberry.net>
In-Reply-To: <QoU2sZuraBPD8Ak_h7dueHinUBEXa-y2P0riVkyeZM7d1iwOMVjQHaEQB7BESm7fjDgKh2z9BSyC7gsxAKAsWz5ssi5UsGtZw8eJstR2IWQ=@marionberry.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 17 Feb 2026 10:07:27 -0800
Message-ID: <CABcZeBP93tQPcZQ4Qa8kdYyn4Of3VyvcEcpgKjMa1v+67sWY-A@mail.gmail.com>
To: Joshua <joshua=40marionberry.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000db7f0a064b08f3f1"
Message-ID-Hash: VLZXIVYDBZW5K677E7M6KRNBQ33TDPDW
CC: tls@ietf.org
Precedence: list
Subject: [TLS] Re: forwarding draft-ietf-tls-mlkem-05 use case
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k70x1ehYrtxljXgYZ4LUEgotHgc>

I generally agree with the points others have made here, but I'm also
inclined to heavily discount this kind of anonymous input. The converse of
the expectation that people speak for themselves is that people actually
speak up.

-Ekr


On Tue, Feb 17, 2026 at 9:34 AM Joshua <joshua=
40marionberry.net@dmarc.ietf.org> wrote:

> 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
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

[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