How are key exchange and signature algorithms negotiated in TLS 1.3

Question

In TLS 1.2, the cipher suite lists the algorithms for everything (key exchange, signature, cipher/MAC). So by choosing a suite, all the algorithms will have been negotiated. And I can see them from the Security tab in Chrome DevTools, such as:

TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM or

TLS 1.2, ECDHE_ECDSA with X25519, and CHACHA20_POLY1305

In TLS 1.3, the key exchange and signature algorithms are no longer included in the cipher suite. So I'm wondering how they are negotiated. Are they negotiated by a separate method? And is there a way I can find out which algorithms are chosen? In Chrome DevTools, I see results like:

TLS 1.3, X25519, and AES_128_GCM or

TLS 1.3, X25519, and CHACHA20_POLY1305

Which only tells me Curve25519 is picked. It seems the following combinations of key exchange and signature algorithms are all possible: FFDHE_ECDSA, FFDHE_EdDSA, ECDHE_RSA, ECDHE_ECDSA, ECDHE_EdDSA

So how do I tell?

Answer 1

Summary

Key Exchange Method (eg. DHE, PSK or DHE+PSK), negotiated using the pre_shared_key and psk_key_exchange_modes extensions.

Diffie-Hellman group used for the DHE (eg. ffdhe8192, secp256r1, etc.), negociated using the supported_groups extension.

Signature schemes used for authentication (eg. ecdsa_secp256r1_sha256), negotiated using the signature_algorithms extension.

Signature schemes accepted in certificates, negotiated using either the signature_algorithms extension or the signature_algorithms_cert extension.

Key Exchange methods

TLS v1.3 supports three key exchange methods:

• ephemeral Diffie-Hellman (combined with digital signatures for authentication);
• PSK with ephemeral Diffie-Hellman;
• PSK without ephemeral Diffie-Hellman.

The client announces that it intends to use one of the PSK methods by proposing one or several PSK identities to the server through the pre_shared_key extension of the ClientHello. In addition, it has to use the psk_key_exchange_modes extensions as well in order to declare which of the two PSK methods it supports.

If the server accepts one of the proposed PSK identities, its answer includes the pre_shared_key extension in the ServerHello. This extension indicates which of the proposed PSK identities it has chosen to accept.

See the diagram in the TLS v1.3 specification.

If the client did not propose any PSK identity or if the server did not accept any of the proposed PSK identities, ephemeral Diffie-Hellman key exchange mode is used.

Note: in TLS v1.3, Diffie-Hellman covers both FFDH and ECDH. The group used for the Diffie-Hellman key agreement is negotiated using the supported_groups extension.

Signature algorithm for authentication

The signature algorithms used for authentication (CertificateVerify messages) are negotiated using the signature_algorithms extension:

• the signature_algorithms extension in the ClientHello message is used by the client to announce which signature algorithms it can accept for the server authentication;
• the signature_algorithms extension in the CertificateRequest message is used by the server to announce which signature algorithms it can accept for the client authentication.

Signature algorithm for certificates

If the set of signature algorithms supported for the signatures embedded in the certificates is different, they are announced using the signature_algorithms_cert extension.

Interpreting the output of ChromeDevTools

FFDHE_ECDSA, FFDHE_EdDSA, ECDHE_RSA, ECDHE_ECDSA, ECDHE_EdDSA

These key exchange algorithm names are not actually relevant in TLS v1.3 because the signature algorithm used for authentication is negotiated independently of the key exchange method and of the key exchange group.

TLS 1.3, X25519, and AES_128_GCM or TLS 1.3, X25519, and CHACHA20_POLY1305

Which only tells me Curve25519 is picked.

X25519 is the group used for the Diffie-Hellman key exchange. This can actually be seen in the details of ChromeDeveTools:

Protocol: QUIC

Key exchange group: X25519

Cipher: AES_128_GCM

As X25519 is an elliptic curve group, this mean you are using an ephemeral elliptic-curve Diffie-Hellman key exchange (ECDHE).

You (apparently) cannot directly see which signature algorithm has been used in ChromeDevTools but you can get some information by looking at the leaf certificate sent by the server. For example, when connecting to www.google.com, I get a certificate of type Elliptic Curve P-256. As a consequence, the signature scheme used is going to be ecdsa_secp256r1_sha256.

This is similar to ECDHE_ECDSA in TLS v1.2.