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

[Joseph Salowey <[e-mail]>]

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