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

[John Mattsson <[e-mail]>]

I missed that Meta used ML-KEM-512 as an optimization. My interest was for middlebox traversal when connections using X25519MLKEM768 are dropped. In those cases, the fallback options are X25519 or ML-KEM-512. Today it could be argued that the risk of implementation bugs in ML-KEM is higher than the quantum threat to X25519, but that balance will shift in a few years. My interest in TLS is internal telecom networks, not the public Internet or enterprise environments.

I hope I am wrong, but my expectation is that some middleboxes blocking X25519MLKEM768 will still be around in 2030–2035, when I would prefer to phase out standalone ECC.

John

From: Deirdre Connolly <[e-mail]>
Date: Friday, 28 November 2025 at 15:57
To: John Mattsson <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

> Yes, Meta has a good article on the topic

> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/

This is a good article— I want to highlight that Meta deployed Kyber/ML-KEM-512 only on their internal connections, and don't seem to have any plans to roll that out to their external connections. While -512 nicely fits existing infra, and I agree it should be available especially for IoT settings and internal deployments like Meta's, in general public internet settings it seems to be a a little riskier as a right-on-the-line parameter set for NIST Level 1 security than say -768, which has more headroom security-wise.

On Fri, Nov 28, 2025, 2:17 AM John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> wrote:
Hi Stephen,

>Do you know if anyone's written up a description of that?

Yes, Meta has a good article on the topic

https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/<https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/?utm_source=chatgpt.com>

There has also been quite a lot written about middleboxes, load-balancers, and other software that assume the ClientHello always fits in a single packet. See e.g.,

https://blog.cloudflare.com/pq-2025/
https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-07.html

Just looking at the key share sizes, it is quite easy to see that you can use ML-KEM-512 (800 bytes) and would have been able to fit X25519MLKEM512 (832 bytes) and still fit ClientHello in a single packet. It is also quite easy to see that it for many PMTUs it is problematic to fit ML-KEM-768 (1184 bytes) and X25519MLKEM768 (1216 bytes) in a single packet.

https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/
https://tls13.xargs.org/#client-hello
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

While it did argue for X25519MLKEM512 (and X448MLKEM1024) I did not understand at the time that I would have wanted X25519MLKEM512 for middlebox traversal. Then I would have argued harder for X25519MLKEM512.

The current situation is that OpenSSL 3.5 LTS has shipped with X25519MLKEM768, ML-KEM-512, ML-KEM-768, and ML-KEM-1024 and even if TLS WG standardise X25519MLKEM512 now, it will take several more years until it would be added to a OpenSSL LTS, which a lot of infrastructure is based on. That would make it hard to meet 2030 deadlines for PQC migration but would meet 2035 deadlines. I can live with ML-KEM-512 for middle box traversal, but if TLS WG does not publish ML-KEM-512, I would suggest that X25519MLKEM512 is added to draft-ietf-tls-ecdhe-mlkem.

(Regarding misbehaving servers, if they don’t handle fragmented ClientHello they likely don’t support ML-KEM anyway and you need to retry with standalone X25519. Middleboxes and load-balancers is the big problem)

Cheers,
John

On 2025-11-27, 20:43, "Stephen Farrell" <[e-mail]<mailto:[e-mail]>> 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?

Thanks,
S.


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