[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 11:33 AM Simon Josefsson <simon=
[e-mail]> wrote:

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

Again, this isn't what Recommended=Y/N means in the context
of TLS. Rather, it means that it's generally OK, which is why we have
four separate recommended EC curves.

The mechanism for encouraging implementors to actually use/deploy
a draft is SHOULD/MUST implement.

 -Ekr

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