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 mechanism we will discuss in the next section.
Figure 12.13: Mechanism for updating TLS application traffic secrets
The TLS 1.3 specification recommends Alice and Bob to delete the n-th server/client application traffic secret and its associated key once the n + 1-th secret has been derived and corresponding traffic keys have been computed.
This is another example of a best practice in applied cryptography and security engineering: as soon as cryptographic material is no longer needed, it should be deleted so it cannot fall into Eve’s hands. In practice, this means that any device that temporarily stores user’s secrets should have an easy-to-invoke function for secure decommissioning.
12.5 TLS keys
TLS uses two types of secret keys. The Handshake Traffic Keys are are used for the encryption of the TLS handshake traffic. They are derived from the TLS secrets:
- Alice’s key is derived from server˙handshake˙traffic˙secret
- Bob’s key is derived from client˙handshake˙traffic˙secret
The Application Traffic Keys are used to encrypt the bulk application data that Bob and Alice transmit during their TLS session. Similar to handshake traffic keys, they are also generated from two different secrets:
- server˙application˙traffic˙secret for Alice’s key
- client˙application˙traffic˙secret for Bob’s key
Alice uses her handshake traffic key to encrypt one or more messages to Bob during the TLS handshake: EncryptedExtensions and, optionally, CertificateRequest, Certificate, and CertificateVerify.
The EncryptedExtensions message contains a list of extensions not necessary for establishing TLS secrets and, in turn, TLS keys. This is an important protocol design decision in TLS 1.3. Previous TLS versions did not have such a mechanism and all data in Alice’s reply was transmitted in plaintext. As a result, Eve was able to learn a lot of interesting information about the TLS connection between Alice and Bob. In TLS 1.3, all this information is encrypted.
When Alice authenticates herself to Bob using a certificate, she can optionally request that Bob also prove his identity using a certificate of his own. Alice does this by sending Bob the CertificateRequest message.
The Certificate message contains Alice’s certificate chain which Bob can use to verify Alice’s identity. In addition, the CertificateVerify message contains an explicit proof that Alice indeed knows the private key corresponding to the certificate that vouches her identity. Finally, Alice also encrypts her Finished message using her handshake traffic key.
Don’t worry if some aspects of certificates are unclear to you, such as certificate chains. In a nutshell, certificate chains are sequences of certificates linked together to establish a transitive trust chain from a root certificate to an end-entity certificate. We will cover this topic in detail in Chapter 10, Digital Certificates and Certificate Authorities.
Bob uses his handshake traffic key to encrypt the two optional TLS messages, Certificate and CertificateVerify. Analogous to Alice, Bob uses his handshake traffic key to encrypt his Finished message.
Figure 12.14 shows which TLS messages are encrypted using Alice’s and Bob’s handshake traffic and application traffic keys. Messages encrypted with Alice’s handshake traffic key are shown as { ⋅ }kA, and those encrypted with Bob’s handshake traffic key as { ⋅ }kB. Messages encrypted with Alice’s application traffic key are denoted as [ ⋅ ]kA. Messages encrypted with Bob’s application traffic key are shown as [ ⋅ ]kB. An asterisk ∗ denotes optional TLS messages.
