>I don't follow your line of thought here. A client can send no keyshares in >the ClientHello, and only advertise support for X25519MLKEM768. That's >compatible with RFC 8446, no?
True From: Bas Westerbaan <[email protected]> Date: Saturday, 29 November 2025 at 10:06 To: John Mattsson <[email protected]> Cc: Deirdre Connolly <[email protected]>, [email protected] <[email protected]> Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) But HRR is only a short-term solution, long-term I would like to not support negotiation of standalone ECC, and a client advertising suport of X25519 and then closing the connection if that is actually negotiated is not very nice and to my understanding not compatible RFC 8446. I don't follow your line of thought here. A client can send no keyshares in the ClientHello, and only advertise support for X25519MLKEM768. That's compatible with RFC 8446, no? Cheers, John Preuß Mattsson From: Bas Westerbaan <[email protected]<mailto:[email protected]>> Date: Saturday, 29 November 2025 at 05:16 To: John Mattsson <[email protected]<mailto:[email protected]>> Cc: Deirdre Connolly <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) I know John is not talking about the public web, but I would like to mention that there we do have fragmented ClientHello even with ML-KEM-512. John, I'm curious: how well is the HelloRetryRequest flow supported in your environment? That is: advertise support for X25519MLKEM768 but don't send it, and then have the server ask for it using HelloRetryRequest. In our experiments to origins, we didn't see any issues with this flow and enabled it by default. We did see some servers that do not support PQ also not supporting HelloRetryRequest (to a non PQ curve they do support). Hopefully this is just a server side problem and not a middlebox, but we can't tell that apart just yet. On Fri, Nov 28, 2025 at 5:45 PM John Mattsson <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Date: Friday, 28 November 2025 at 15:57 To: John Mattsson <[email protected]<mailto:[email protected]>> Cc: Stephen Farrell <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[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. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
