What's the deal with X25519 Support in Chrome/Firefox?

Question

RFC8446/TLSv1.3 Section 9.1 says that "implementations SHOULD support X25519".

An online list of software supporting Curve25519 list both Firefox and /Chrome as supporting it for TLS.

I did an experiment and created a self-signed TLS cert with Ed25519. Both Chromium 84 and Firefox 79 complain about not being able to negotiate the cipher list/version. I've also noticed that they initiate TLSv1.2 handshakes when connecting to localhost, but use TLSv1.3 handshakes when connecting to google for example. wget on the other hand, has no problem connecting (I used --no-check-certificate, but afaik that shouldn't matter here)

I then looked at the TLSv1.3 handshakes. neither browser offers Ed25519 as a signature in their ClientHello (even when connecting to google via TLSv1.3). Again, wget does offer it as part of the ClientHello.

So I figured this might be a platform issue with my distro (Fedora), but this Blog Post also claims that the major browsers don't supports X25519. While ChromeStatus says it's been supported since Chrome 50 (I'm assuming chrome and upstream chromium do not differ in this).

I'm totally confused. What's the current state of X25519 support on major browsers? is it a google chrome vs. upstream chromium issue?

Answer 1

... Section 9.1 says that "implementations SHOULD support X25519"

While you seem to quote from the RFC the phrase in question is actually significantly different from what you quote:

9.1. Mandatory-to-Implement Cipher Suites

... SHOULD support key exchange with X25519 [RFC7748].

But what you tried is using a certificate with an Ed25519 based public key for authentication which is completely different from using X25519 for key exchange. X25519 key exchange seems to be actually implemented in the browsers, but Ed25519 certificates not.

... neither browser offers Ed25519 as a signature in their ClientHello

There are no Ed25519 signatures involved in X25519. X25519 is a key exchange - which is supported by browsers. Ed25519 is instead a signature algorithm - which is not supported. X25519 and Ed25519 are thus different things which both use Curve25519.

Answer 2

As @steffan pointed out, I was confusing X25519 (ECDH Key Exchange) with ED25519 (Digital signatures).

Chrome supports X25519 (for DH key exchange), but not ED25519.

Also, There's more than one place where the supported algorithms for different aspects of the protocol are listed in the handshake.

Comparing the handshake for wget and chromium:

wget:

Chromium:

The curves supported for key exchange are passed in the supported_groups extension. As the screenshot shows, Chrome does offer X25519 there.

There are two other extensions in which ED25519 may appear.

First, the CertificateVerify extension which is used to sign the handshake. The "supported_signatures" extension declares which signature algorithms the client supports.

Second, there are the signature algorithms supported for certificates. According to the RFC, this should be declared in a "signature_algorithms_cert" extension, but according to section 4.2.3:

The "signature_algorithms_cert" extension applies to signatures in certificates, and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages.

But:

If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates.

Finally, Section 9.1 says:

A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256.

A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].