Draft: draft-ietf-tls-ticketrequests

Commentary: This is without ticket re - use text . This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths . Did I get this right ? Does this make sense ? Should we put this in the document directly ? 
 do you think we should include the table in the PR 's description in the text ? I think its contents are implied from the text , so adding more text is just being verbose . But I could be persuaded otherwise . 
 I think that it might be confusing . For instance , I see no reason that a client would n't have a fixed configuration . A client that never races resumptions could send N and 1 always . 
 Can you please provide text ? 
 I ca n't really provide text as I 'm unclear on what the field is trying to even describe .
As per RFC5077, and as described in RFC8446, TLS servers vend clients
an arbitrary number of session tickets at their own discretion in
NewSessionTicket messages.  There are two limitations with this
design.  First, servers choose some (often hard-coded) number of
tickets vended per connection.  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.
As per RFC5077, and as described in RFC8446, TLS servers vend clients
an arbitrary number of session tickets at their own discretion in
NewSessionTicket messages.  There are at least three limitations with
this design.
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.
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques
for performing connection racing.  The Transport Services
Architecture implementation from TAPS also describes how
connections can race across interfaces and address families.  In
cases where clients have early data to send and want to minimize
or avoid ticket re-use, unique tickets for each unique connection
attempt are useful.  Moreover, as some servers may implement
single-use tickets (and even session ticket encryption keys),
distinct tickets will be needed to prevent premature ticket
invalidation by racing.
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques
for performing connection racing.  The Transport Services
Architecture implementation from TAPS also describes how
connections can race across interfaces and address families.  In
such cases, clients may use more than one ticket while racing
connection attempts in order to establish one successful
connection.  Having multiple tickets equips clients with enough
tickets to initiate connection racing while avoiding ticket re-use
and ensuring that their cache of tickets does not empty during
such races.  Moreover, as some servers may implement single-use
tickets, distinct tickets prevent premature ticket invalidation by
racing.
The number of tickets desired by the client.
Clients can use TicketRequestContents.count to indicate the number of
tickets they would prefer to receive.  Servers SHOULD NOT send more
tickets than TicketRequestContents.count, as clients will most likely
discard any additional tickets.  Servers SHOULD additionally place a
limit on the number of tickets they are willing to send, to save
resources.  Therefore, the number of NewSessionTicket messages sent
will typically be the minimum of the server's self-imposed limit and
TicketRequestContents.count.
A server that supports ticket requests MAY echo the "ticket_request"
extension in the EncryptedExtensions message.  If present, it
contains a TicketRequestContents structure, where
TicketRequestContents.count indicates the number of tickets the
server expects to send to the client.
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 the server expects to send in this
connection.
If a client receives a HelloRetryRequest, the presence (or absence)
of the "ticket_request" extension MUST be maintained in the second
ClientHello message.  Moreover, if this extension is present, a
client MUST NOT change the value of TicketRequestContents.count in
the second ClientHello message.
If a client receives a HelloRetryRequest, the presence (or absence)
of the "ticket_request" extension MUST be maintained in the second
ClientHello message.  Moreover, if this extension is present, a
client MUST NOT change the value of ClientTicketRequest in the second
ClientHello message.