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

[Bas Westerbaan <[e-mail]>]

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 <john.mattsson=
[e-mail]> 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 <[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]> 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]> 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]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>