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

[Watson Ladd <[e-mail]>]

I haven't seen anyone say they don't want to see a Y by
X25519MLKEM768. Since this is the widespread and adopted solution
right now, we should do everything we can to encourage use, and punt
on the harder question of what other hybrids to recommend.

On Tue, Oct 7, 2025 at 11:32 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.
>
> 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]
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim