Key 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 HKDF-Expand-Label function as described previously. Similarly, Bob’s new traffic key is generated by first computing this:
client_application_traffic_secret_N+1 = HKDF-Expand-Label(client_application_traffic_secret_N, “traffic upd”, “”, Hash.length)
Afterwards, HKDF-Expand-Label is applied to generate the new traffic key.
After having seen how the TLS keys are generated from the TLS secrets, we now take a detailed look at what exactly the TLS handshake messages for agreeing on a cryptographic setting and shared keys look like.
12.6 TLS key exchange messages
During the TLS handshake, the Bob and the Alice negotiate the cryptographic settings for the key establishment and agree upon shared secret keys using Key Exchange Messages. These keys are used to protect the later part of the handshake itself as well as the subsequent application data transmitted between Bob and Alice.
We saw in Chapter 6, Transport Layer Security at a Glance, that there are a number of different handshake messages used depending on the chosen key exchange option and the current state of the protocol.
The handshake messages must be sent in the order specified by the TLS protocol. Whenever Alice or Bob receive an out-of-order handshake message, they immediately abort the handshake and signal the error by transmitting the unexpected˙alert message.
This illustrates two good practices in cryptographic protocol design. First, the expected order of messages must be unambiguous in any given situation to avoid misinterpretations both on Alice’s and on Bob’s side. Second, because any deviation from the specified protocol must be treated as a potential attack attempt, the protocol must be stopped immediately, and the other party must be notified about the cause of the failure. The error message not only allows the other party to terminate the protocol but also leaves an audit trace for a potential investigation later on.
Technically speaking, handshake messages are transmitted by passing them to the TLS record layer, where they are encapsulated into one or more TLSPlaintext or TLSCiphertext data structures.