TLS Ticket Requests
Extracted elements (24)
Clients can send a ticket request with count zero to explicitly indicate they do not intend to resume a connection, reducing server-side ticket generation waste when resumption is not desired.
The extension shifts ticket count determination from servers (which currently use hard-coded or application-specific logic) to clients, who have direct knowledge of their concurrency needs (e.g., parallel HTTP connections, Happy Eyeballs racing), thereby reducing ticket waste and avoiding reuse.
The extension uses separate new_session_count and resumption_count fields because clients may need different numbers of tickets for new versus resumed connections — e.g., a resumption_count of 1 suffices when the cache is primed, but more tickets are needed after a forced full handshake that invalidates all prior tickets.
Clients racing multiple connections using Happy Eyeballs V2 should set resumption_count equal to the number of parallel connection attempts to avoid running out of tickets; sending a resumption_count less than the number of parallel attempts may result in zero tickets.
The 'ticket_request' extension is only applicable to TLS 1.3 (RFC 8446), DTLS 1.3 (RFC 9147), and future versions of (D)TLS; it cannot be used with earlier protocol versions.
A client MUST abort the connection with an 'illegal_parameter' alert if the 'ticket_request' extension is present in any server handshake message other than EncryptedExtensions.
A client starting a new connection SHOULD set new_session_count to the desired number of session tickets and resumption_count to 0.
A server that supports and uses a client 'ticket_request' extension MUST also send the 'ticket_request' extension in the EncryptedExtensions message.
Clients MAY send the 'ticket_request' extension in ClientHello to indicate the desired number of session tickets.
Clients MUST NOT cache tickets for longer than 7 days, as specified in Section 4.6.1 of RFC 8446.
Clients SHOULD dispose of cached tickets after some reasonable amount of time that mimics the session ticket encryption key rotation period.
If a client receives a HelloRetryRequest, the presence or absence of the 'ticket_request' extension MUST be maintained in the second ClientHello, and the client MUST NOT change the value of ClientTicketRequest.
Servers MUST NOT send the 'ticket_request' extension in any handshake message other than EncryptedExtensions, including ServerHello or HelloRetryRequest messages.
Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address, to prevent amplification attacks via spoofed DTLS packets.
Servers SHOULD NOT send more tickets than requested for the connection type selected (new or resumed), and SHOULD place a limit on tickets they are willing to send to save resources.
When a client presenting a previously obtained ticket finds the server negotiates a new connection, the client SHOULD assume all other tickets associated with the same session are also no longer valid for resumption.
Servers MAY send additional NewSessionTicket messages beyond the initially requested count using the same limit if the originally sent tickets are somehow invalidated, allowing clients to maintain a healthy ticket cache.
The 'ticket_request' extension (type value 58) is a new TLS extension clients can send in ClientHello to express their desired number of session tickets. It is only applicable to TLS 1.3, DTLS 1.3, and future versions of (D)TLS.
IANA added entry value 58 with extension name 'ticket_request' to the 'TLS ExtensionType Values' registry. It is applicable in ClientHello (CH) and EncryptedExtensions (EE) messages, is not DTLS-only, and is marked Recommended=Y.
In DTLS, a server sending NewSessionTicket messages before verifying client IP ownership enables an amplification attack: an attacker can spoof client packets to direct a flood of ticket messages proportional to the requested count toward a target.
Servers that do not enforce a limit on NewSessionTicket messages in response to a 'ticket_request' extension are vulnerable to DoS attacks, especially when ticket creation involves expensive operations such as public key cryptography.
Ticket reuse is a security and privacy concern. Clients must take care when pooling tickets; if servers do not rotate session ticket encryption keys frequently, clients may be encouraged to use tickets beyond reasonable lifetime windows such as 24 hours.
The ClientTicketRequest structure contains two uint8 fields: 'new_session_count' (tickets desired for a new connection) and 'resumption_count' (tickets desired for a resumed connection). Each field is one octet.
The ServerTicketRequestHint structure contains a single uint8 field 'expected_count' indicating the number of tickets the server expects to send. It is carried in the EncryptedExtensions message.