HelloRetryRequest – 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 HelloRetryRequest contains the supported˙versions extension to tell Bob which TLS version Alice is using. In addition, it typically includes a minimal set of TLS extensions that tell Bob how – if this is possible for him – to adjust his choice of cryptographic parameters, transmitted in the subsequent ClientHello, so they match what Alice supports. With the exception of the optional cookie extension, HelloRetryRequest may not contain any extensions that Bob did not offer in his initial ClientHello message.
Upon receiving HelloRetryRequest, Bob uses the supported˙versions, cipher˙suite, and legacy-related TLS extensions we previously described to find out which TLS version Alice supports. If the information in these extensions has no effect on Bob’s cryptographic parameter choice – that is, if it does not change the ClientHello message – Bob terminates the handshake and sends the illegal˙parameter message to Alice.
Bob also terminates the handshake and sends Alice an unexpected˙message message if he receives a second HelloRetryRequest message in the same TLS connection.
If none of the conditions for terminating the handshake apply, Bob processes all extensions he received from Alice in the HelloRetryRequest message and replies with an updated ClientHello to match Alice’s settings.
If Bob receives a HelloRetryRequest message with a cipher suite that he did not offer in ClientHello, he terminates the handshake. Moreover, when Bob receives a second ServerHello (following HelloRetryRequest and the updated ClientHello messages), he checks that the cipher suite in HelloRetryRequest is identical to that in the second ServerHello. If this is not the case, Bob terminates the handshakes and sends Alice an illegal˙parameter message.
Finally, Alice’s TLS version in the supported˙versions extension in the HelloRetryRequest message must be identical to the TLS version in the second ServerHello message. Otherwise, Bob terminates the handshake and sends Alice an illegal˙parameter message.
This finishes our discussion of the TLS key exchange messages. Because of the many possible options, but also because of the need for backward compatibility, this was a rather lengthy and technical section.
12.7 Summary
In this chapter, we took a detailed look at the TLS specification and the various secrets and keys it defines. Specifically, we have seen how different keys used for different contexts are derived from initial secrets – either PSKs or a secret coming from a Diffie-Hellman key exchange.
We have also tried to highlight various best practices in cryptography engineering deployed within TLS: different keys for different purposes, well-defined fallback and alert procedures in case of protocol errors, and the destruction of obsolete keying material. In the next chapter, we will take a step back and