Updating TLS secrets – Secrets and Keys in TLS 1.3
12.4 Updating TLS secrets At any time after a successful handshake, Alice and Bob can update their application traffic keys using the KeyUpdate message. They accomplish this by first deriving new secrets server˙application˙traffic˙secret˙N+1 and client˙application˙traffic˙secret˙N+1 using the HKDF-Expand-Label function HEL as shown in Figure 12.13. After that, new application traffic keys are computed using a…
Read MoreExporter values – Secrets and Keys in TLS 1.3
12.5.1 Exporter values Exporter values are computed using the Derive-Secret DS and the HKDF-Expand-Label HEL functions as shown in Figure 12.15. The input secret can be either early˙exporter˙master˙secret or exporter˙master˙secret. Bob and Alice use early˙exporter˙master˙secret when they need an exporter for 0-RTT data. For all other cases, the TLS 1.3 standard requires them to use…
Read MoreKey update – Secrets and Keys in TLS 1.3
12.5.3 Key update After the TLS handshake, both Alice and Bob can update their traffic keys at any point in time by sending the KeyUpdate message. Alice’s new traffic key is generated by deriving server˙application˙traffic˙secret˙N+1 from server˙application˙traffic˙secret˙N as follows:server_application_traffic_secret_N+1 = HKDF-Expand-Label(server_application_traffic_secret_N, “traffic upd”, “”, Hash.length) After that, the new traffic key is computed using the…
Read MoreCryptographic 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…
Read MoreClientHello 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…
Read MoreClientHello – 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…
Read MoreServerHello – Secrets and Keys in TLS 1.3
12.6.3 ServerHello Upon receiving a ClientHello message from Bob, Alice responds with the ServerHello message to continue the TLS handshake – if Alice is able to select a feasible set of cryptographic parameters based on the choices offered by Bob in his ClientHello message. The structure of ServerHello is shown in Listing 12.3. Listing 12.3:…
Read MoreHelloRetryRequest – Secrets and Keys in TLS 1.3
12.6.4 HelloRetryRequest If Alice receives a ClientHello message from Bob with a set of cryptographic parameters that Alice does not support or does not want to use, she responds with a HelloRetryRequest message. HelloRetryRequest has the same format as the ServerHello message, and the legacy˙version, legacy˙session˙id˙echo, cipher˙suite, legacy˙compression˙method message fields have the same meaning. Alice’s…
Read MoreTLS client state machine – TLS Handshake Protocol Revisited
13.1 TLS client state machine Appendix A of RFC 8446, the IETF specification of TLS 1.3, summarizes valid states and state transitions for TLS 1.3 server and client. The client state machine is shown in Figure 13.1. Labels in square brackets indicate actions the client performs only under specific circumstances. Label k = x indicates…
Read MoreTLS server state machine – TLS Handshake Protocol Revisited
13.2 TLS server state machine The server state machine is shown in Figure 13.2. Like with the client state machine, labels in square brackets indicate actions that the server performs only under specific circumstances. Figure 13.2: State machine and state transitions of a TLS 1.3 server For server Alice, the TLS handshake is triggered by…
Read More