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/ <a6ef545e-941a-4fbd-943b-1060d0942a56> 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 <4432e17e-38b5-412a-af3b-891f621da89f> 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/ <color: rgb(0, 0, 0); text-decoration: none;> https://tls13.xargs.org/#client-hello https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf <color: rgb(0, 0, 0); text-decoration: none;> 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" <[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
