[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Bas Westerbaan <[e-mail]>]

This is the breakdown of client support Cloudflare sees (relative to any PQ
support) in the last 24 hours by handshakes:

94% X25519MLKEM768
8.1% X25519Kyber768
0.038% MLKEM768
0.014% CECPQ2
0.012% MLKEM1024
0.002% SecP384MLKEM1024
0.002% SecP256MLKEM768
0.00005% MLKEM512
0.0000003% SecP256Kyber768

If we ignore the CECPQ2 and Kyber hybrids, then X25519MLKEM768 is supported
by 99.992% of clients that offer PQ.

Again ignoring CECPQ2 and Kyber, we see the following shares sent in the
ClientHello.

99.96% [X25519MLKEM768]
0.02% [X25519MLKEM768, MLKEM768]
0.007% [MLKEM768, MLKEM1024]
0.005% [X25519MLKEM768, MLKEM768, MLKEM1024]
0.002% [X25519MLKEM768, SecP256MLKEM768, SecP384MLKEM1024]
(...)
0.00001% [MLKEM512, MLKEM768, MLKEM1024]
(...)
0.0000003% [SecP256MLKEM768, SecP384MLKEM768]

(X25519MLKEM768 is in all the unlisted ClientHello's)

It is wise to keep the set of recommended algorithms as small as possible
as there is a real cost to fragmentation. We welcome
draft-ietf-tls-key-share-prediction which offsets the performance impact of
the HelloRetryRequest if we do get worse fragmentation, but not every
client will be able to use it and not every server will be able to
provision the DNS records.

I can see an argument for Recommended=Y for both X25519MLKEM768 and
SecP384MLKEM1024, but I do not see any value in recommending both
X25519MLKEM768 and SecP256MLKEM768.

At the moment we only support X25519MLKEM768 and X25519Kyber768, and have
no immediate plans to change that except for disabling X25519Kyber768 at
some point.

Best,

Bas


On Tue, Oct 7, 2025 at 4:52 PM Eric Rescorla <[e-mail]> wrote:

> I have reviewed this document and I think it is ready to go with
> one exception, namely the Recommended column.
>
> The RFC 8447 standard for "Recommended=Y" is:
>
>    Per this document, a "Recommended" column has been added to many of
>    the TLS registries to indicate parameters that are generally
>    recommended for implementations to support.
>
> I think there's a general expectation that we want people to
> implement and deploy these algorithms, and I would expect
> that the X25519 and P-256 versions to be widely deployed,
> at least on the Web. Therefore, I think we should mark all of
> these as Recommended=Y. I note that this would require
> advancing this document as Proposed Standard. We should do
> that as well.
>
> -Ekr
>
>
>
>
> On Tue, Oct 7, 2025 at 6:47 AM Joseph Salowey <[e-mail]> wrote:
>
>> This is the working group last call for Post-quantum hybrid ECDHE-MLKEM
>> Key Agreement for TLSv1.3. Please review draft-ietf-tls-ecdhe-mlkem [1] and
>> reply to this thread indicating if you think it is ready for publication or
>> not.  If you do not think it is ready please indicate why.  This call will
>> end on October 22, 2025.
>>
>> Please note that during the WG adoption call, Dan Bernstein pointed out
>> some potential IPR (see [2]), but no IPR disclosure has been made in
>> accordance with BCP 79.  Additional information is provided here; see [3].
>>
>> BCP 79 makes this important point:
>>
>>  (b) The IETF, following normal processes, can decide to use
>>    technology for which IPR disclosures have been made if it decides
>>    that such a use is warranted.
>>
>> WG members can take this information into account during the working
>> group last call.
>>
>> Reminder:  This working group last call has nothing to do with picking
>> the mandatory-to-implement cipher suites in TLS.
>>
>> Cheers,
>> Joe & Sean
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
>> [2]
>> https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
>> [3]
>> https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
>>
>> _______________________________________________
>> 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]
>