> 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= [email protected]> 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 <[email protected]> > *Date: *Saturday, 28 February 2026 at 08:56 > *To: *[email protected] <[email protected]> > *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", 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 -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
