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

[Eric Rescorla <[e-mail]>]

On Tue, Oct 7, 2025 at 9:28 AM Bas Westerbaan <[e-mail]> wrote:

> 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.
>

I could live with that.

-Ekr



> 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]
>>
>