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

[Bas Westerbaan <[e-mail]>]

>
> 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 <bas=[e-mail]>
> *Date: *Saturday, 29 November 2025 at 05:16
> *To: *John Mattsson <[e-mail]>
> *Cc: *Deirdre Connolly <[e-mail]>, [e-mail] <
> [e-mail]>
> *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 <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]
>
>