On Mon, 3 Jun 2024 at 01:03, Filippo Valsorda <fili...@ml.filippo.io> wrote: > > I expect X25519 to be the most commonly selected (as opposed to supported) > TLS key exchange on the open Internet, due to browsers preferring it for its > marginal performance benefit. This is not a popularity contest though and > that's not the most useful metric for choosing the ECC component of a PQC > hybrid. > > The most important performance consideration in TLS is avoiding Hello Retry > Request round-trips due to the server supporting none of the client's key > shares. Moreover, clients want to reuse the ECC component of the hybrid key > share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, > X25519+ML-KEM-768 so that the X25519 key generation can be reused). > > Given those goals, the important metric is server support. We should indeed > collect data on what are the most supported key exchanges server-side, > probably weighted by website or implementation popularity. (I expect X25519 > and P-256 to have nearly equivalent support, maybe with some FIPS-related > delta in favor of P-256.) > > I actually meant to bring this up, because as an implementer I also want to > avoid proliferation of hybrid options, but it would actually make my life > much easier if the one universal hybrid (and/or default client key share) was > P-256+ML-KEM-768. > > The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by > the CA/B Baseline Requirements. This is not changing soon. That means I am on > the hook to carry an optimized and secure P-256 implementation no matter what.
Maybe it's time for WebPKI to have more flexibility. They are going to have to make changes anyway. Might as well push forward for Ed25519 ? > > If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am > also on the hook to carry an optimized and secure X25519 implementation. > That's double the work, double the opportunity for mistakes, double the > complexity, double the attack surface. > > If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 > becomes much less important, and I can carry a simpler less efficient (e.g. > without assembly) implementation for it, and focus my limited resources on > P-256. My personal view is that it's important to have at least one "independent" curve like X25519 in hybrid mode for TLS in addition to the NIST approved curve, even at the cost of a little bit of performance. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
