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

[Simon Josefsson <[e-mail]>]

The discussion below suggests to me that X25519MLKEM768 is the running
code de-facto algorithm that ought to be on the Standards Track and
Recommended=Y and the other variants should be split off to a separate
Informational document with Recommended=N for niche usage.

I believe generally that we need multiple PQ-safe hybrids as Standards
Track and MUST/Recommended algorithms for all our Internet security
protocols like TLS, SSH, etc, so I would encourage deployment of
additional PQ-safe hybrids for TLS.  Settling with X25519MLKEM768 only
is not the final solution.

Mitigating algorithm profileration is a consideration, but security
heding is more important.  It would be nice to get X25519 combined with
FrodoKEM, Classic McEliece, SNTRU, and more deployed for TLS too, so we
have options.  I believe it makes more sense to add some other PQ KEM as
a StandardsTrack/MUST/Recommended than to have SecP256MLKEM768 there.
In fact, I would go further and say that we should progress two at the
same time, to not get into a single point of failure situation.

/Simon

Jan Schaumann <jschauma=[e-mail]> writes:

> Bas Westerbaan <bas=[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
>
> [...]
>
>> 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.
>
> On the flip side, and as just some data points here, I
> recently did a check[1] of which sites/providers offer
> PQC, and what key groups they support.  Not
> surprisingly, it's almost all (and _only_)
> X25519MLKEM768.
>
> Amazon Cloudfront (as pretty much the only large
> service provider) offers SecP256r1MLKEM768.
>
> This is not surprising: AFAICT, the browsers only
> support X25519MLKEM768.  If no servers offer anything
> else, then browsers have no incentive to implement
> other key groups; if no browsers offer other
> keygroups, then servers have no incentive to offer
> them.
>
> -Jan
>
> [1] https://www.netmeister.org/blog/pqc-use-2025-09.html
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]