Error handling in the TLS 1.3 handshake – Transport Layer Security at a Glance
6.6.2 Error handling in the TLS 1.3 handshake
In applied cryptography – similar to most other engineering areas that require some form of dependability – it is generally a good practice to plan for failure. The TLS standard specifies how to deal with failures during the initial handshake.
Figure 6.8: Message flow in TLS handshake with mismatched cryptographic parameters
In TLS, the so-called key˙share extension contains the endpoint’s cryptographic parameters, such as the elliptic curves and finite fields, that the endpoint supports for calculations performed during the TLS handshake.
If the client provides parameters, for example, the set of specific cryptographic algorithms or a key˙share extension it wants to use for the TLS handshake, that are not supported by the server, the server replies with a HelloRetryRequest message. As shown in Figure 6.8, this message tells the client to restart the handshake with suitable cryptographic parameters.
If the client and the server cannot agree on cryptographic parameters that they both support, the server terminates the handshake and sends a corresponding message to the client.
For security reasons, the handshake transcript includes the initial ClientHello, HelloRetryRequest message exchange. The transcript is not reset with a new ClientHello message so that the cryptographic parameter re-negotiated is visible in the logs.
6.6.3 Session resumption and PSKs
As mentioned earlier in this chapter, in addition to an ad hoc key establishment using the handshake protocol, TLS also supports the use of pre-shared secret keys.
Note that the RFC 8446 document refers to a shared secret key as a pre-shared key. To a certain extent, this makes sense in order to differentiate between a secret key that was freshly established during the most recent handshake and a secret key established previous to the current execution of the TLS protocol. Fundamentally, however, any shared secret key must be established in advance. The terms pre-shared secret key and shared secret key are therefore equivalent in connection with session resumption, even if this blurs the distinction between previously shared long-term secrets and short-term (ephemeral) keys that have been established in a previous TLS session.
The long-term keys can be shared out of band, that is, not over the communication channel that is to be protected using TLS. As an example, Alice and Bob could meet in private to exchange the keys, pretty much how Pretty Good Privacy (PGP) keys are vouched for at PGP signing parties.
Figure 6.9: Message flow in TLS session resumption: initial handshake
Alternatively, the secret keys could have been established in a previous TLS session. In this case, TLS allows the establishment of a new TLS connection using these keys. This is called session resumption (see also Section 6.5.3, Session resumption, where it was discussed in the context of TLS version 1.2).
After a successful handshake – that is, after authenticating the server or both, the server and the client – the server sends the client the identity of a unique symmetric key derived during a previous handshake. In response, the client can use the identity of that shared key in future TLS handshakes if it wants to use that key again.
When the server accepts that shared key, the new TLS connection is cryptographically linked to the original TLS connection. In other words, the key established during the original handshake is used to shorten the process instead of executing a full TLS handshake.
TLS allows us to use PSKs in conjunction with a cryptographic key agreement protocol such as Diffie-Hellmann to ensure forward secrecy for session resumption. Alternatively, the pre-shared secret keys can be used as is. In this case, however, forward secrecy is not achieved. By now, you should know why this is so: if a PSK is used without an accompanying public-key-based key agreement protocol, losing it will compromise all sessions that used that key, including earlier sessions. If, on the other hand, the PSK is only used to provide authenticity to public keys, only future sessions are compromised, because in future sessions Eve might impersonate Alice or Bob.
Figure 6.9 shows the initial TLS handshake where the shared secret key is established. Figure 6.10 shows the subsequent TLS handshake that uses the previously established key instead of performing a full key agreement. When a server authenticates itself using a PSK, neither Certificate nor CertificateVerify messages are sent. Rather, the server transmits a message telling the client to use the PSK.
Figure 6.10: Message flow in TLS session resumption: subsequent handshake
In general, when pre-shared keys are used with TLS, they must have sufficient entropy (see Chapter 3, A Secret to Share). If Eve observes the handshake between Alice and Bob where a PSK is used, she can perform a brute-force attack on that key.