Draft: draft-ietf-tls-ticketrequests

Commentary: I opted to go with " new connection " instead of " full handshake " ( where appropriate ) , since that seemed to be the more natural phrase . Please let me know what you think ! cc ( and thanks for the review ! )
First, servers vend some (often hard-coded) number of tickets per
connection.  Some server implementations return a different default
number of tickets for session resumption than for the initial full
handshake that created the session.  No static choice, whether fixed,
or resumption-dependent is ideal for all situations.
Second, clients do not have a way of expressing their desired number
of tickets, which can impact future connection establishment.  For
example, clients can open multiple TLS connections to the same server
for HTTP, or race TLS connections across different network
interfaces.  The latter is especially useful in transport systems
that implement Happy Eyeballs RFC8305.  Since clients control
connection concurrency and resumption, a standard mechanism for
requesting more than one ticket is desirable.
Third, all tickets in the client's possession ultimately derive from
some initial full handshake.  Especially when the client was
initially authenticated with a client certificate, that session may
need to be refreshed from time to time.  Consequently, a server may
periodically force a full handshake even when the client presents a
valid ticket.  When that happens, it is possible that any other
tickets derived from the same original session are equally invalid.
A client avoids a full handshake on subsequent connections if it
replaces all stored tickets with fresh ones obtained from the just
performed full handshake.  The number of tickets the server should
vend for a full handshake may therefore need to be larger than the
number for routine resumption.
This document specifies a new TLS extension - "ticket_request" - that
can be used by clients to express their desired number of session
tickets.  Servers can use this extension as a hint for the number of
NewSessionTicket messages to vend.  This extension is only applicable
to TLS 1.3 RFC8446, DTLS 1.3 I-D.ietf-tls-dtls13, and future versions
of (D)TLS.
First, servers vend some (often hard-coded) number of tickets per
connection.  Some server implementations return a different default
number of tickets for session resumption than for the initial
connection that created the session.  No static choice, whether
fixed, or resumption-dependent is ideal for all situations.
Second, clients do not have a way of expressing their desired number
of tickets, which can impact future connection establishment.  For
example, clients can open parallel TLS connections to the same server
for HTTP, or race TLS connections across different network
interfaces.  The latter is especially useful in transport systems
that implement Happy Eyeballs RFC8305.  Since clients control
connection concurrency and resumption, a standard mechanism for
requesting more than one ticket is desirable for avoiding ticket
reuse.  See RFC8446, Appendix C.4 for discussion of ticket reuse
risks.
Third, all tickets in the client's possession ultimately derive from
some initial connection.  Especially when the client was initially
authenticated with a client certificate, that session may need to be
refreshed from time to time.  Consequently, a server may periodically
force a new connection even when the client presents a valid ticket.
When that happens, it is possible that any other tickets derived from
the same original session are equally invalid.  A client avoids a
full handshake on subsequent connections if it replaces all stored
tickets with new ones obtained from the just performed full
handshake.  The number of tickets the server should vend for a new
connection may therefore need to be larger than the number for
routine resumption.
This document specifies a new TLS extension - "ticket_request" - that
clients can use to express their desired number of session tickets.
Servers can use this extension as a hint for the number of
NewSessionTicket messages to vend.  This extension is only applicable
to TLS 1.3 RFC8446, DTLS 1.3 I-D.ietf-tls-dtls13, and future versions
of (D)TLS.
The number of tickets desired by the client when the server
chooses to negotiate a fresh session (full handshake).
When a client presenting a previously obtained ticket finds that the
server nevertheless negotiates a fresh session, the client SHOULD
assume that any other tickets associated with the same session as the
presented ticket are also no longer valid for resumption.  This
includes tickets obtained during the initial full handshake and all
tickets subsequently obtained as part of subsequent resumptions.
Requesting more than one ticket in cases when servers select a full
handshake helps keep the session cache primed.
Servers SHOULD NOT send more tickets than requested for the handshake
type selected by the server (resumption or full handshake).
Moreover, servers SHOULD place a limit on the number of tickets they
are willing to send, whether for full handshakes or resumptions, to
save resources.  Therefore, the number of NewSessionTicket messages
sent will typically be the minimum of the server's self-imposed limit
and the number requested.  Servers MAY send additional tickets, up to
the same limit, if the tickets that are originally sent are somehow
invalidated.
The number of tickets desired by the client when the server
chooses to negotiate a new connection.
When a client presenting a previously obtained ticket finds that the
server nevertheless negotiates a new connection, the client SHOULD
assume that any other tickets associated with the same session as the
presented ticket are also no longer valid for resumption.  This
includes tickets obtained during the initial (new) connection and all
tickets subsequently obtained as part of subsequent resumptions.
Requesting more than one ticket in cases when servers complete a new
connection helps keep the session cache primed.
Servers SHOULD NOT send more tickets than requested for the
connection type selected by the server (new or resumed connection).
Moreover, servers SHOULD place a limit on the number of tickets they
are willing to send, whether for new or resumed connections, to save
resources.  Therefore, the number of NewSessionTicket messages sent
will typically be the minimum of the server's self-imposed limit and
the number requested.  Servers MAY send additional tickets, typically
using the same limit, if the tickets that are originally sent are
somehow invalidated.
Servers MUST NOT send the "ticket_request" extension in ServerHello
or HelloRetryRequest messages.  A client MUST abort the connection
with an "illegal_parameter" alert if the "ticket_request" extension
is present in either of these messages.
Servers MUST NOT send the "ticket_request" extension in any handshake
message, including ServerHello or HelloRetryRequest messages.  A
client MUST abort the connection with an "illegal_parameter" alert if
the "ticket_request" extension is present in any server handshake
message.
Ticket re-use is a security and privacy concern.  Moreover, clients
must take care when pooling tickets as a means of avoiding or
amortizing handshake costs.  If servers do not rotate session ticket
encryption keys frequently, clients may be encouraged to obtain and
use tickets beyond common lifetime windows of, e.g., 24 hours.
Despite ticket lifetime hints provided by servers, clients SHOULD
dispose of pooled tickets after some reasonable amount of time that
mimics the session ticket encryption key rotation period.
Ticket re-use is a security and privacy concern.  Moreover, clients
must take care when pooling tickets as a means of avoiding or
amortizing handshake costs.  If servers do not rotate session ticket
encryption keys frequently, clients may be encouraged to obtain and
use tickets beyond common lifetime windows of, e.g., 24 hours.
Despite ticket lifetime hints provided by servers, clients SHOULD
dispose of cached tickets after some reasonable amount of time that
mimics the session ticket encryption key rotation period.
Specifically, as specified in Section 4.6.1 of RFC8446, clients MUST
NOT cache tickets for longer than 7 days.