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

[David Adrian <[e-mail]>]

I believe the document is ready for publication. I am fine publishing
as-is, or with a X25519MLKEM768 as a Recommended=Y. I have no opinions on
the other key agreements.



On Tue, Oct 7, 2025 at 11:44 AM Watson Ladd <[e-mail]> wrote:

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