ClientHello – Secrets and Keys in TLS 1.3
12.6.2 ClientHello
According to TLS specification, ClientHello must be the first message Bob sends to Alice. Bob must also send ClientHello if Alice has responded with HelloRetryRequest message because of a mismatch in their cryptographic parameters. In the latter case, Bob must respond with the same ClientHello message, altering only specific parameter values.
If HelloRetryRequest contains a key˙share extension, Bob must adjust his list of key shares to include a key share from the indicated group. If Bob’s initial ClientHello message contained the early˙data extension, it must be removed from subsequent ClientHello because the TLS specification forbids sending early data after a HelloRetryRequest response.
If Alice’s HelloRetryRequest response includes a cookie extension, Bob must add this extension to his subsequent ClientHello. This extension allows Alice to offload state information to Bob, so she can send HelloRetryRequest without storing the state.
Finally, if it is present, Bob may update the pre˙shared˙key extension and, optionally, add, remove, or alter the padding extension length. The fact that only specific changes are permitted to ClientHello illustrates another interesting aspect: the TLS 1.3 specification deliberately reduces the complexity of the protocol and, thus, the complexity of the software or hardware needed to execute the protocol, by limiting the number of valid changes. As we saw in Chapter 1, Role of Cryptography in the Connected World, complexity is an enemy of security. So, in practice, this simple constraint helps to prevent implementation bugs that might turn into security vulnerabilities.
Another notable TLS 1.3 design decision is to forbid renegotiation. If Alice successfully completes the cryptographic negotiation with Bob, but later on – at any point in time – receives a ClientHello message, Alice terminates their TLS connection and sends Bob the unexpected˙message message. This is a new feature within TLS 1.3 that was added because of earlier Renegotiation Attacks, in which an attacker Mallory makes the victim send a request for a protected resource to a TLS server. This request is stored by the attacker and not forwarded to the server. Instead Mallory sets up a TLS session of her own and requests a different protected resource. To authenticate the request, many TLS servers initiated a session renegotiation by sending a new ServerHello message. The attacker can now respond with the stored ClientHello message from the stored earlier request.
The basic problem here is that there is no logical connection between requests made within different TLS sessions. In order to avoid these problems, session renegotiation is forbidden in TLS 1.3 even if a TLS session in an earlier version is to be renegotiated to version 1.3. In other words, if Alice has established a TLS connection based on a version of TLS previous to 1.3, and she receives a TLS 1.3 ClientHello in a renegotiation, she must stick to the previous TLS protocol version. The detailed structure of the ClientHello message is shown in Listing 12.2.
The legacy˙version constant exists for historical reasons. Previous to TLS 1.3, this message field indicated the highest TLS version number that Bob supports, and it was used to negotiate the TLS version between Bob and Alice.