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?

  • 1
    See tls13.ulfheim.net for a walkthrough of a TLS 1.3 session.
    – mti2935
    Commented Dec 7, 2021 at 19:55
  • @mti2935 Thanks a lot for the link! It's very helpful & informative. There's just one thing that puzzles me. In the example, the client gives three curves in "supported groups" of "client hello". However, in the "key share" extension (as well as in the "client key exchange generation"), the client just picks the "x25519" curve and computes & sends the public key for that curve. What if the server wants to pick a different curve?
    – Linda Wu
    Commented Dec 8, 2021 at 4:57

1 Answer 1



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:

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


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.

  • Thanks so much for the detailed explanations and pointers! It gives me the high level idea and complements the step-by-step illustration link given by mti2935 in the comment. Thanks also for helping with Interpreting the output of ChromeDevTools! I now found all the information you mentioned. There's only one thing not yet clear to me, regarding key exchange. The TLS diagram you gave shows "ClientHello + key_share" from the client. Since the server hasn't picked a curve from the supported groups yet, does that mean the client has to compute & send her public key for every curve she supports?
    – Linda Wu
    Commented Dec 8, 2021 at 4:48
  • 1
    @LindaWu: no. Client can initially send one, more than one, or zero proposed shares; if server does not find any proposed share it accepts (and PSK is not used/available, e.g. resumption), but does find a supported_group it would accept, it sends HelloRetryRequest to tell the client to use (offer) that group. In RFC8446 see 4.2.8, 4.1.2, 4.1.4 and the diagram in 2.1 (page 14). In fact if you want to know about TLS1.3 in general, reading RFC8446 is an excellent idea. Commented Dec 8, 2021 at 5:12
  • @dave_thompson_085 Thank you very much for your answer and the reference! That clear things up for me.
    – Linda Wu
    Commented Dec 8, 2021 at 7:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .