[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[John Mattsson <[e-mail]>]

Thanks, 2. solves all the middlebox issues I have. I do not have any use of standalone ML-KEM for middlebox traversal. I can live with an extra RTT.

Cheers,
John

From: David Benjamin <[e-mail]>
Date: Saturday, 28 February 2026 at 17:13
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

> Continuing to support the quantum-vulnerable X25519 and relying on the server to request HRR are not ideal but may work in the short term.

The two halves of this are unrelated.

1. Clients may still need to support legacy algorithms like X25519. However, the reason for doing this is not this middlebox issue. You need to support legacy algorithms for compatibility if and only if you still need to connect to servers that are too old to support ML-KEM. If all the servers you support also support ML-KEM, then you can drop legacy algorithms like X25519.

2. If you cannot send ML-KEM in the initial ClientHello due to some faulty middlebox, you can opt to omit ML-KEM in the key share list and expect the server to send HelloRetryRequest. We happily did not need this on the Web, but if your deployment needs it, that option is available. There is no need to continue supporting X25519 to do this. You can send zero key shares in your initial ClientHello if that is what you want.

> the only viable long-term solution may be to upgrade or replace the problematic middleboxes.

Yes. This is the path we took on the Web and it seems to have gone fine. Faulty middleboxes should get replaced.

On Sat, Feb 28, 2026 at 5:16 AM John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I received a lot of valuable feedback in November and would phrase things differently now. I agree that X25519MLKEM768 and HRR can be used for middlebox traversal. Continuing to support the quantum-vulnerable X25519 and relying on the server to request HRR are not ideal but may work in the short term. During testing of X25519MLKEM768 in a telecom network, we encountered significant issues with legacy servers and middleboxes. I don’t have enough data to determine whether these problems are common or specific to this network. It was also pointed out that fitting an ML-KEM-512 CH into a single segment is challenging, so the only viable long-term solution may be to upgrade or replace the problematic middleboxes.

John

From: Viktor Dukhovni <[e-mail]<mailto:[e-mail]>>
Date: Saturday, 28 February 2026 at 08:56
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

On Thu, Nov 27, 2025 at 07:43:57PM +0000, Stephen Farrell wrote:

> Hi John,
>
> On 27/11/2025 16:02, John Mattsson wrote:
> > - ML-KEM-512 is the only adopted quantum-resistant algorithm that
> > can be used to bypass legacy middle boxes.
>
> Do you know if anyone's written up a description of that?

Though some SMTP servers (often noticeably slower to upgrade than the
Web), problems with multi-TCP-segment ML-KEM client hellos have been
reported by senders to a few receiving domains, such reports are fairly
rare.  One notable problem site (at the time "boeing.com<http://boeing.com/>", was promptly
remediated).

I am inclined to be sceptical of the claim that middleboxes are a
significant barrier to adoption of MLKEM768.  If necessary clients can
include X25519MLKEM768 near the front of their supported groups list,
but without sending a corresponding predicted keyshare, and then at
the cost of an HRR negotiate its use with just the servers that support
and prefer it.  This is the approach taken in the default settings of
the Postfix SMTP client, where admittedly an accasionaly extra
round-trip is not a concern, and in any case server support for PQ key
exchange will be fairly rare for a while.

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

_______________________________________________
TLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
TLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>