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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> writes: > > > > > Bas Westerbaan <[email protected]> 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 -- [email protected] > > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
