The working group last call for pure ML-KEM has concluded, thanks to those that participated in the discussion. In summary, we do not have consensus to publish the document as is.
The largest number of participants wanted to publish the document as is, however there was also a significant number that wanted changes to the document before publication and a small, but vocal, number of participants that do not want the document to be published at all. There were several issues raised, but the main area of contention was around having a statement on the security and applicability of this mechanism versus the hybrid key mechanisms. Given this, the chairs will move the document back to the "WG Document" state and ask the author to work on resolving the issues brought up on the list including text to address concerns that there are reasons to prefer hybrid over the pure approach. The chairs will then redo a working group last call to see if there is rough consensus for publishing this document. Thanks Joe and Sean On Sat, Nov 29, 2025 at 1:06 AM Bas Westerbaan <bas= [email protected]> wrote: > 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]> >> *Date: *Saturday, 29 November 2025 at 05:16 >> *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) >> >> 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= >> [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]> >> *Date: *Friday, 28 November 2025 at 15:57 >> *To: *John Mattsson <[email protected]> >> *Cc: *Stephen Farrell <[email protected]>, [email protected] < >> [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 <john.mattsson= >> [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]> >> 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] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
