ClientHello 2 – Secrets and Keys in TLS 1.3
Listing 12.2: ClientHello message structure
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
In turned out, however, that the implementation of TLS version negotiation was flawed in many TLS servers. As a result, servers would reject a well-formed ClientHello message where the TLS version number was higher than the one supported by the server.
To resolve this Version Intolerance issue in TLS 1.3, Bob communicates his preferred TLS versions in the supported˙versions extension. The legacy˙version field must be set to the constant 0x0303 which stands for TLS version 1.2.
Thus, Alice recognizes the TLS 1.3 ClientHello message based on the value 0x0303 of the legacy˙version field and the value 0x0304 present in the supported˙versions extension as the highest TLS version supported by Bob.
The random field in the ClientHello message contains a 32-byte random number generated using a cryptographically secure random number generator. We will see in the following chapters what this number is used for.
As the name indicates, legacy˙session˙id is another legacy field in the ClientHello message. Prior to version 1.3, TLS had a dedicated session resumption feature. In TLS 1.3, this feature was merged with PSKs, in that the secret negotiated in the previous session is treated like a PSK in the resumed session. In the current TLS version, this field is set to 0 unless compatibility mode is used (see RFC 8446 [147], Appendix D, for details).
cipher˙suites lists symmetric cryptography settings supported by Bob. In particular, cipher˙suites includes the symmetric algorithm for protecting TLS records as well as the hash function to be used in the HKDF algorithm, for example, TLS˙AES˙256˙GCM˙SHA384. These settings are listed in Bob’s descending preference order.
If cipher˙suites lists cipher suites that Alice does not know, cannot compute, or does not want to use, she must ignore these cipher suites and treat others as usual. If Bob wants to perform the TLS handshake using a PSK, he has to indicate at least one cipher suite that defines the hash function to be used with the PSK for deriving further secrets using an HKDF.
The legacy˙compression˙methods field is also a legacy from previous TLS versions and must be set to 0 in TLS 1.3. Prior to version 1.3, TLS supported compression. The algorithms supported by Bob were listed in legacy˙compression˙methods. The mandatory value 0 in TLS 1.3 corresponds to no compression, and Alice is required to terminate the TLS handshake – and send Bob an illegal˙parameter message – if this field has any value different from zero. However, if a TLS 1.3 server receives a version 1.2 or earlier ClientHello message, it must follow the protocol defined for that specific TLS version.
Using the extensions field, Bob can request extended functionality from Alice. If Bob sends an extension request, Alice typically answers with the corresponding extension response. If Bob requests extended functionality that is not supported by Alice, Bob may terminate the TLS handshake.
In TLS 1.3, the ClientHello message always contains extensions because it includes the mandatory supported˙versions extension. If this is not the case, Alice will interpret that ClientHello as a TLS 1.2 message.
Once Bob transmits ClientHello, he must wait for a ServerHello or HelloRetryRequest message from Alice. In addition, if Bob uses early data, he may send this data to Alice while waiting for her next handshake message.