Cryptographic negotiation – Secrets and Keys in TLS 1.3
12.6.1 Cryptographic negotiation
Bob, the client, starts cryptographic negotiation by sending the ClientHello message to Alice, the server. This message contains the information about Bob’s crytographic capabilities.
The first piece of information in ClientHello is a list of Authenticated Encryption with Associated Data (AEAD) algorithms and HKDFs that Bob can compute. We will have more to tell about these specific algorithms in Chapter 15, Authenticated Encryption, and Chapter 11, Hash Functions and Message Authenication Codes, respectively.
In TLS jargon, such combinations of cryptographic algorithms supported by an endpoint are referred to as cipher suites, and ClientHello contains a list of symmetric cipher suites defining pairs of AEAD and HKDF algorithms that the client supports.
TLS defines the naming convention for symmetric cipher suites as TLS_AEAD_HASH = VALUE, where TLS stands for the TLS protocol, AEAD denotes the AEAD algorithm for protecting TLS records together with the key size, HASH is the hash function used in HKDF, and VALUE is a two-byte identifier assigned to that particular cipher suite in the TLS specification. As an example, the symmetric cipher suite TLS˙AES˙128˙GCM˙SHA256 refers to the AEAD scheme based on the AES block cipher in Galois Counter Mode (GCM) with 128 bits as the key size and SHA-256 as the hash functions. This cipher suite has the associated identifier 0x13,0x01.
The supported˙groups and key˙share extensions contain the second piece of cryptographic information in the ClientHello message. A TLS extension is simply a data structure composed of the extension type (defined in the TLS standard) and extension data specific to that extension type:
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
The supported˙groups extension tells Alice (the server) which groups Bob is able to use for the DHE- or ECDHE-related computations. The key˙share extension lists the DHE or ECDHE shares for some or all of these groups. We will have more to say about these topics in Chapter 8, Elliptic Curves. For now, it is sufficient to know that Alice and Bob need to agree on these parameters to be able to use the Diffie-Hellman key agreement we briefly touched upon in previous chapters.
ClientHello further contains the signature˙algorithms extension. It lists digital signature algorithms that Bob (the client) can use. As a result, Alice must use one of these algorithms so that Bob can verify Alice’s digital signature.
Moreover, Bob can add signature˙algorithms˙cert to the ClientHello message indicating certificate-specific signature algorithms. These are the signature algorithms Bob is able to support for verification of the digital signature of a certificate.
Finally, ClientHello might contain the pre˙shared˙key extension listing the identities of all symmetric keys known to Bob, the client, as well as the psk˙key˙exchange˙modes extension that tells Alice, the server, which specific key exchange modes can be used with the pre-shared symmetric keys.
This is a good example of how interoperability between different communicating parties can be achieved in a secure manner. Essentially, Bob proposes to Alice a set of options he considers secure and Alice can choose any subset she wants and deems to be secure. Because these cryptographic options are defined in the TLS 1.3 standard, only secure choices are possible (note that in older TLS versions, there are still insecure choices available). If Alice and Bob cannot agree on a common subset, Alice terminates the protocol.
This scheme ensures an important security property. While the endpoints’ capability to negotiate is retained – and so the protocol works with a wide range of systems – neither Bob nor Alice can force the protocol to use insecure cryptographic parameters. If this were possible, Eve could impersonate one of the endpoints and break TLS security by supplying weak parameters. In Chapter 7, Public-Key Encryption, we will see in detail why this would work.
If Alice chooses to establish shared secret keys for the secure communication channel using DH or ECDH key agreement, she selects the cipher suite, the DH or ECDH group and the key share, and the signature algorithm and the certificate to authenticate herself to Bob. For this to work, however, Alice’s choices must match one of the values in Bob’s supported˙groups and signature˙algorithms extensions. If this is not the case, the TLS protocol specification requires Alice to terminate the handshake and to send Bob a handshake˙failure or insufficient˙security message.
Here we see another example of a good practice in (cryptographic) protocol design: the response to a protocol failure and the error handling are well defined. Namely, if the parameter negotiation is unsuccessful, the protocol is terminated. It is also exactly specified which communicating party does what: Alice terminates the handshake and sends an error message to Bob. The error handling itself is explicit and well defined – transmission of a handshake˙failure or insufficient˙security message – and so leaves a kind of paper trail that’s useful for debugging, auditing, or digital forensics.
If Alice chooses to use a PSK instead, she needs to select one of the key establishment modes listed in Bob’s psk˙key˙exchange˙modes extension in the ClientHello message. If the PSK is used alone, that is, without combining it with DH or ECDH key agreement, it doesn’t matter whether Alice supports any of the parameters listed in Bob’s supported˙groups extension.
If Alice selects a DH or ECDH group that does not match Bob’s key˙share extension in the initial ClientHello message, Alice has to reply with a HelloRetryRequest message. Otherwise, if there is an overlap between the cryptographic parameters chosen by Alice and the cryptographic parameters offered by Bob, Alice indicates her choices in the ServerHello message, a reply to ClientHello.
If a PSK shall be used, ServerHello contains the pre˙shared˙key extension telling Bob which PSK he needs to select. If the DH or ECDH key agreement shall be used, ServerHello contains the key˙share extension with Alice’s DH or ECDH key share.
In addition, if Alice authenticates herself to Bob using a digital certificate (more on digital certificates in Chapter 10, Digital Certificates and Certification Authorities), Alice will transmit to Bob the messages Certificate and CertificateVerify.