The NewSessionTicket message – TLS Handshake Protocol Revisited
13.5.1 The NewSessionTicket message
Any time after receiving Bob’s Finished message, Alice can send a NewSessionTicket message. NewSessionTicket creates a unique link between the value of the ticket and the secret pre-shared key that is derived from resumption˙master˙secret (see Section 12.2, TLS secrets, in Chapter 12, Secrets and Keys in TLS 1.3, for more details).
Bob, in turn, can use this pre-shared key for future handshakes with Alice by including that ticket value in the pre˙shared˙key extension in his ClientHello message.
Alice can also send Bob multiple tickets. As an example, she could send a new ticket following the post-handshake authentication so she can encapsulate the additional client authentication state. Moreover, multiple tickets are beneficial for Bob if he wants to open multiple HTTPS connections to Alice in parallel or to speed up connection setup across address families and interfaces using a technique such as Happy Eyeballs, as specified in RFC 8305.
Importantly, every ticket can only be resumed with a TLS cipher suite that has the same KDF hash function as the one used during the establishment of the original connection. Moreover, Bob is only allowed to resume if the new SNI value is valid for Alice’s certificate that she used to prove her identity to Bob in the original TLS session.
The structure of the NewSessionTicket message is shown in Listing 13.3. The element ticket˙lifetime contains the lifetime of the ticket in seconds, defined from the time the ticket was issued. The maximum value Alice is allowed to use is 604,800 seconds, which is equivalent to seven days. If ticket˙lifetime is set to zero, the ticket should be discarded immediately.
Listing 13.3: Structure of the NewSessionTicket message
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
Moreover, Bob is not allowed to cache a ticket for longer than seven days regardless of the ticket˙lifetime value, and he may discard the ticket earlier according to his local policy. Alice, on the other hand, can treat a ticket as valid for a shorter time period than the ticket˙lifetime value.
The ticket˙age˙add variable stores a random, securely generated value used for obscuring the age of the ticket that Bob includes in his pre˙shared˙key extension. This value is added to Bob’s ticket age modulo 232 to obtain an obscured value that is then sent by Bob. Alice generates a fresh ticket˙age˙add value for every ticket she sends.
ticket˙nonce is a unique value across all tickets that Alice issues in the same TLS connection. ticket is the ticket value used as the pre-shared secret key (PSK) identity. The ticket itself maybe either a self-encrypted, self-authenticated value or a database lookup key.
Finally, the extensions variable contains a set of extension values for that ticket. At the time of this writing, the only extension that the TLS 1.3 standard defines for the NewSessionTicket message is early˙data, which indicates that the ticket can be used to send 0-RTT data. It contains the max˙early˙data˙size value, which defines the maximum number of bytes of 0-RTT data that Bob may send using this ticket.
The pre-shared secret key associated with the ticket is computed as follows:
HKDF-Expand-Label(resumption_master_secret, “resumption”, ticket_nonce, Hash.length)
Recall that since ticket˙nonce is unique for every NewSessionTicket message in a given TLS session, a different pre-shared secret key will be generated for every ticket. Technically, Alice could issue new tickets to indefinitely extend the lifetime of the keying material derived during the initial non-PSK handshake. However, TLS specification recommends limiting the total lifetime of such keying material based on the lifetime of Bob’s certificate, the likelihood of certificate revocation, and the time since Bob’s CertificateVerify signature.