rfc9149.original.xml   rfc9149.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
<!ENTITY RFC8305 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8305.xml">
<!ENTITY I-D.ietf-taps-impl SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/
reference.I-D.ietf-taps-impl.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-tls-ticketrequests-07" category="
std" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2021-04-02T20:38:38Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="*o+-"?>
<?rfc toc="yes"?>
<front>
<title>TLS Ticket Requests</title>
<author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
<address><postal><street>One Apple Park Way</street>
<street>Cupertino, California 95014,</street>
<street>United States of America</street>
</postal>
<email>tpauly@apple.com</email>
</address>
</author>
<author initials="D." surname="Schinazi" fullname="David Schinazi"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Google LLC</organization>
<address><postal><street>1600 Amphitheatre Parkway</street>
<street>Mountain View, California 94043,</street>
<street>United States of America</street>
</postal>
<email>dschinazi.ietf@gmail.com</email>
</address>
</author>
<author initials="C.A." surname="Wood" fullname="Christopher A. Wood"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-tls-ticketre
<organization>Cloudflare</organization> quests-07" number="9149" submissionType="IETF" category="std" consensus="true" i
<address><postal><street>101 Townsend St</street> pr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="
<street>San Francisco,</street> true" tocInclude="true"
<street>United States of America</street> version="3">
</postal>
<email>caw@heapingbits.net</email>
</address>
</author>
<date year="2020" month="December"/> <!-- [rfced] FYI: This document normatively references RFC-to-be 9147
<abstract><t> (draft-ietf-tls-dtls13), which will enter AUTH48 soon. If this document
is ready for publication before RFC-to-be 9147 (i.e., all questions have
been addressed and all authors have approved), we will wait to publish
until RFC-to-be 9147 is also ready.
-->
<front>
<title>TLS Ticket Requests</title>
<seriesInfo name="RFC" value="9149"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country>
</postal>
<email>tpauly@apple.com</email>
</address>
</author>
<author initials="D." surname="Schinazi" fullname="David Schinazi">
<organization>Google LLC</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>United States of America</country>
</postal>
<email>dschinazi.ietf@gmail.com</email>
</address>
</author>
<author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
<address>
<postal>
<street>101 Townsend St</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>United States of America</country>
</postal>
<email>caw@heapingbits.net</email>
</address>
</author>
<date year="2021" month="August"/>
<keyword>TLS</keyword>
<keyword>Tickets</keyword>
<abstract>
<t>
TLS session tickets enable stateless connection resumption for TLS session tickets enable stateless connection resumption for
clients without server-side, per-client, state. Servers vend an clients without server-side, per-client state. Servers vend an
arbitrary number of session tickets to clients, at their discretion, arbitrary number of session tickets to clients, at their discretion,
upon connection establishment. Clients store and use tickets when upon connection establishment. Clients store and use tickets when
resuming future connections. This document describes a mechanism by resuming future connections. This document describes a mechanism by
which clients can specify the desired number of tickets needed for which clients can specify the desired number of tickets needed for
future connections. This extension aims to provide a means for future connections. This extension aims to provide a means for
servers to determine the number of tickets to generate in order to servers to determine the number of tickets to generate in order to
reduce ticket waste, while simultaneously priming clients for future reduce ticket waste while simultaneously priming clients for future
connection attempts.</t> connection attempts.</t>
</abstract>
</abstract> </front>
<note title="Discussion Venues"><t> <middle>
This note is to be removed before publishing as an RFC.</t> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/tlswg/draft-ietf-tls-ticketrequest"/>.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="sect-1"><t>
As as described in <xref target="RFC8446"/>, TLS servers vend clients an arbi
trary
number of session tickets at their own discretion in NewSessionTicket
messages. There are at least three limitations with this design.</t>
<t> <t>
As described in <xref target="RFC8446" format="default"/>, 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.</t>
<t>
First, servers vend some (often hard-coded) number of tickets per First, servers vend some (often hard-coded) number of tickets per
connection. Some server implementations return a different default connection. Some server implementations return a different default number
number of tickets for session resumption than for the initial of tickets for session resumption than for the initial connection that
connection that created the session. No static choice, whether created the session. No static choice, whether fixed or dependent upon
fixed, or resumption-dependent is ideal for all situations.</t> resumption, is ideal for all situations.</t>
<t>
<t> Second, clients do not have a way of expressing their desired number of
Second, clients do not have a way of expressing their desired number tickets, which can impact future connection establishment. For example,
of tickets, which can impact future connection establishment. For clients can open parallel TLS connections to the same server for HTTP, or
example, clients can open parallel TLS connections to the same server they can race TLS connections across different network interfaces. The
for HTTP, or race TLS connections across different network latter is especially useful in transport systems that implement Happy
interfaces. The latter is especially useful in transport systems Eyeballs <xref target="RFC8305" format="default"/>. Since clients control
that implement Happy Eyeballs <xref target="RFC8305"/>. Since clients contro connection concurrency and resumption, a standard mechanism for requesting
l more than one ticket is desirable for avoiding ticket reuse. See <xref
connection concurrency and resumption, a standard mechanism for target="RFC8446" sectionFormat="of" section="C.4" format="default"/> for
requesting more than one ticket is desirable for avoiding ticket discussion of ticket reuse risks.</t>
reuse. See <xref target="RFC8446"/>, Appendix C.4 for discussion of ticket r <t>
euse
risks.</t>
<t>
Third, all tickets in the client's possession ultimately derive from Third, all tickets in the client's possession ultimately derive from
some initial connection. Especially when the client was initially some initial connection. Especially when the client was initially
authenticated with a client certificate, that session may need to be authenticated with a client certificate, that session may need to be
refreshed from time to time. Consequently, a server may periodically refreshed from time to time. Consequently, a server may periodically
force a new connection even when the client presents a valid ticket. force a new connection even when the client presents a valid ticket.
When that happens, it is possible that any other tickets derived from When that happens, it is possible that any other tickets derived from
the same original session are equally invalid. A client avoids a the same original session are equally invalid. A client avoids a
full handshake on subsequent connections if it replaces all stored full handshake on subsequent connections if it replaces all stored
tickets with new ones obtained from the just performed full tickets with new ones obtained from the just-performed full
handshake. The number of tickets the server should vend for a new handshake. The number of tickets the server should vend for a new
connection may therefore need to be larger than the number for connection may therefore need to be larger than the number for
routine resumption.</t> routine resumption.</t>
<t>
<t> This document specifies a new TLS extension, "ticket_request", that
This document specifies a new TLS extension - "ticket_request" - that
clients can use to express their desired number of session tickets. clients can use to express their desired number of session tickets.
Servers can use this extension as a hint for the number of NewSessionTicket 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 <xref messages to vend. This extension is only applicable to TLS 1.3 <xref target=
target="RFC8446"/>, DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/>, and "RFC8446" format="default"/>, DTLS 1.3 <xref target="RFC9147" format="default"/>
, and
future versions of (D)TLS.</t> future versions of (D)TLS.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language" anchor="sect-1.1"><t> The key <t>
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
in this document are to be interpreted as described in <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section title="Use Cases" anchor="sect-2"><t> </section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Use Cases</name>
<t>
The ability to request one or more tickets is useful for a variety of The ability to request one or more tickets is useful for a variety of
purposes:</t> purposes:</t>
<t><list style="symbols"><t>Parallel HTTP connections: To improve perform <dl>
ance, a client may
open parallel connections. To avoid ticket reuse, the client may
use distinct tickets on each connection. Clients must therefore
bound the number of parallel connections they initiate by the
number of tickets in their possession, or risk ticket re-use.</t>
<t>Connection racing: Happy Eyeballs V2 <xref target="RFC8305"/> describe <dt>Parallel HTTP connections:
s </dt>
techniques for performing connection racing. The Transport <dd>To improve performance, a client may open parallel connections. To avoid
Services Architecture implementation from <xref target="I-D.ietf-taps-impl ticket reuse, the client may use distinct tickets on each connection. Clients
"/> also describes must therefore bound the number of parallel connections they initiate by the
how connections can race across interfaces and address families. number of tickets in their possession or risk ticket reuse.
In such cases, clients may use more than one ticket while racing </dd>
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.</t>
<t>Less ticket waste: Currently, TLS servers use application-specific, an <dt>Connection racing:
d </dt>
often implementation-specific, logic to determine how many tickets to
issue. By moving the burden of ticket count to clients, servers do not
generate wasteful tickets. As an example, clients might only request
one ticket during resumption. Moreover, as ticket generation might
involve expensive computation, e.g., public key cryptographic
operations, avoiding waste is desirable.</t>
<t>Decline resumption: Clients can indicate they do not intend to <dd>Happy Eyeballs V2 <xref target="RFC8305" format="default"/> describes
resume a connection by sending a ticket request with count of techniques for performing connection racing. The Transport Services
zero.</t> Implementation document <xref target="I-D.ietf-taps-impl" format="default"/>
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 reuse 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.
</dd>
</list> <dt>Less ticket waste:
</t> </dt>
<dd>Currently, TLS servers use application-specific, and often
implementation-specific, logic to determine how many tickets to issue. By
moving the burden of ticket count to clients, servers do not generate wasteful
tickets. As an example, clients might only request one ticket during
resumption. Moreover, as ticket generation might involve expensive
computation, e.g., public key cryptographic operations, avoiding waste is
desirable.
</dd>
</section> <dt>Decline resumption:</dt>
<dd>Clients can indicate they do not intend to resume a connection by sending
a ticket request with count of zero.
</dd>
<section title="Ticket Requests" anchor="sect-3"><t> </dl>
As discussed in <xref target="sect-1"/>, clients may want different numbers o
f </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Ticket Requests</name>
<t>
As discussed in <xref target="sect-1" format="default"/>, clients may want di
fferent numbers of
tickets for new or resumed connections. Clients may indicate to tickets for new or resumed connections. Clients may indicate to
servers their desired number of tickets to receive on a single servers their desired number of tickets to receive on a single
connection, in the case of a new or resumed connection, via the connection, in the case of a new or resumed connection, via the
following "ticket_request" extension:</t> following "ticket_request" extension:</t>
<figure><artwork><![CDATA[ <!-- [rfced] Please review the <sourcecode> elements in this document and let
us know if a type from the list at
https://www.rfc-editor.org/materials/sourcecode-types.txt should be
entered in the "type" attribute of each element. Note that it is okay to
leave this attribute empty.
-->
<sourcecode type="tls-presentation"><![CDATA[
enum { enum {
ticket_request(TBD), (65535) ticket_request(58), (65535)
} ExtensionType; } ExtensionType;
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> Clients <bcp14>MAY</bcp14> send this extension in ClientHello. It contains t
Clients MAY send this extension in ClientHello. It contains the he
following structure:</t> following structure:</t>
<sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
struct { struct {
uint8 new_session_count; uint8 new_session_count;
uint8 resumption_count; uint8 resumption_count;
} ClientTicketRequest; } ClientTicketRequest;
]]></artwork> ]]></sourcecode>
</figure> <dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"><t hangText="new_session_count"> <dt>new_session_count:</dt>
<dd>
The number of tickets desired by the client if the server chooses to The number of tickets desired by the client if the server chooses to
negotiate a new connection. negotiate a new connection.
</t> </dd>
<dt>resumption_count:</dt>
<t hangText="resumption_count"> <dd>
The number of tickets desired by the client if the The number of tickets desired by the client if the server is willing
server is willing to resume using a ticket presented in this to resume using a ticket presented in this ClientHello.
ClientHello. </dd>
</t> </dl>
<t>
</list> A client starting a new connection <bcp14>SHOULD</bcp14> set new_session_coun
</t> t to
<t>
A client starting a new connection SHOULD set new_session_count to
the desired number of session tickets and resumption_count to 0. the desired number of session tickets and resumption_count to 0.
Once a client's ticket cache is primed, a resumption_count of 1 is a Once a client's ticket cache is primed, a resumption_count of 1 is a
good choice that allows the server to replace each ticket with a new good choice that allows the server to replace each ticket with a new
ticket, without over-provisioning the client with excess tickets. ticket without over-provisioning the client with excess tickets.
However, clients which race multiple connections and place a separate However, clients that race multiple connections and place a separate
ticket in each will ultimately end up with just the tickets from a ticket in each will ultimately end up with just the tickets from a
single resumed session. In that case, clients can send a single resumed session. In that case, clients can send a
resumption_count equal to the number of connections they are resumption_count equal to the number of connections they are
attempting in parallel. (Clients which send a resumption_count less attempting in parallel. (Clients that send a resumption_count less
than the number of parallel connection attempts might end up with than the number of parallel connection attempts might end up with
zero tickets.)</t> zero tickets.)</t>
<t>
<t>
When a client presenting a previously obtained ticket finds that the When a client presenting a previously obtained ticket finds that the
server nevertheless negotiates a new connection, the client SHOULD server nevertheless negotiates a new connection, the client <bcp14>SHOULD</bc p14>
assume that any other tickets associated with the same session as the assume that any other tickets associated with the same session as the
presented ticket are also no longer valid for resumption. This presented ticket are also no longer valid for resumption. This
includes tickets obtained during the initial (new) connection and all includes tickets obtained during the initial (new) connection and all
tickets subsequently obtained as part of subsequent resumptions. tickets subsequently obtained as part of subsequent resumptions.
Requesting more than one ticket in cases when servers complete a new Requesting more than one ticket when servers complete a new
connection helps keep the session cache primed.</t> connection helps keep the session cache primed.</t>
<t>
<t> Servers <bcp14>SHOULD NOT</bcp14> send more tickets than requested for the
Servers SHOULD NOT send more tickets than requested for the
connection type selected by the server (new or resumed connection). connection type selected by the server (new or resumed connection).
Moreover, servers SHOULD place a limit on the number of tickets they Moreover, servers <bcp14>SHOULD</bcp14> place a limit on the number of ticket s they
are willing to send, whether for new or resumed connections, to save are willing to send, whether for new or resumed connections, to save
resources. Therefore, the number of NewSessionTicket messages sent resources. Therefore, the number of NewSessionTicket messages sent
will typically be the minimum of the server's self-imposed limit and will typically be the minimum of the server's self-imposed limit and
the number requested. Servers MAY send additional tickets, typically the number requested. Servers <bcp14>MAY</bcp14> send additional tickets, ty pically
using the same limit, if the tickets that are originally sent are using the same limit, if the tickets that are originally sent are
somehow invalidated.</t> somehow invalidated.</t>
<t>
<t> A server that supports and uses a client "ticket_request" extension
A server which supports and uses a client "ticket_request" extension <bcp14>MUST</bcp14> also send the "ticket_request" extension in the
MUST also send the "ticket_request" extension in the
EncryptedExtensions message. It contains the following structure:</t> EncryptedExtensions message. It contains the following structure:</t>
<sourcecode type="tls-presentation">
<figure><artwork><![CDATA[ <![CDATA[struct {
struct {
uint8 expected_count; uint8 expected_count;
} ServerTicketRequestHint; } ServerTicketRequestHint;
]]></artwork> ]]></sourcecode>
</figure> <dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"><t hangText="expected_count"> <dt>expected_count:</dt>
<dd>
The number of tickets the server expects to send in this connection. The number of tickets the server expects to send in this connection.
</t> </dd>
</dl>
</list> <t>
</t> Servers <bcp14>MUST NOT</bcp14> send the "ticket_request" extension in any ha
ndshake
<t>
Servers MUST NOT send the "ticket_request" extension in any handshake
message, including ServerHello or HelloRetryRequest messages. A message, including ServerHello or HelloRetryRequest messages. A
client MUST abort the connection with an "illegal_parameter" alert if client <bcp14>MUST</bcp14> abort the connection with an "illegal_parameter" a lert if
the "ticket_request" extension is present in any server handshake the "ticket_request" extension is present in any server handshake
message.</t> message.</t>
<t>
<t>
If a client receives a HelloRetryRequest, the presence (or absence) If a client receives a HelloRetryRequest, the presence (or absence)
of the "ticket_request" extension MUST be maintained in the second of the "ticket_request" extension <bcp14>MUST</bcp14> be maintained in the se cond
ClientHello message. Moreover, if this extension is present, a ClientHello message. Moreover, if this extension is present, a
client MUST NOT change the value of ClientTicketRequest in the second client <bcp14>MUST NOT</bcp14> change the value of ClientTicketRequest in the second
ClientHello message.</t> ClientHello message.</t>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>
IANA has added the following entry to the "TLS ExtensionType Values"
<section title="IANA Considerations" anchor="sect-4"><t> registry <xref target="RFC8446" format="default"/> <xref target="RFC8447"
IANA is requested to create an entry, ticket_request(TBD), in the format="default"/>:</t>
existing registry for ExtensionType (defined in <xref target="RFC8446"/>), wi
th "TLS 1.3" column values being set to "CH, EE", and "Recommended" column
being set to "Y".</t>
</section> <table anchor="iana_table">
<name>Addition to TLS ExtensionType Values Registry</name>
<thead>
<tr>
<th>Value</th>
<th>Extension Name</th>
<th>TLS 1.3</th>
<th>DTLS-Only</th>
<th>Recommended</th>
</tr>
</thead>
<tbody>
<tr>
<td>58</td>
<td>ticket_request</td>
<td>CH, EE</td>
<td>N</td>
<td>Y</td>
</tr>
</tbody>
</table>
<section title="Performance Considerations" anchor="sect-5"><t> </section>
<section anchor="sect-5" numbered="true" toc="default">
<name>Performance Considerations</name>
<t>
Servers can send tickets in NewSessionTicket messages any time after Servers can send tickets in NewSessionTicket messages any time after
the server Finished message (see <xref target="RFC8446"/>; Section 4.6.1). A the server Finished message (see <xref target="RFC8446" section="4.6.1" secti
server onFormat="of" format="default"/>). A server
which chooses to send a large number of tickets to a client can that chooses to send a large number of tickets to a client can
potentially harm application performance if the tickets are sent potentially harm application performance if the tickets are sent
before application data. For example, if the transport connection before application data. For example, if the transport connection
has a constrained congestion window, ticket messages could delay has a constrained congestion window, ticket messages could delay
sending application data. To avoid this, servers should prioritize sending application data. To avoid this, servers should prioritize
sending application data over tickets when possible.</t> sending application data over tickets when possible.</t>
</section>
<section anchor="sect-6" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
Ticket reuse 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 <bcp14>SHOULD</bcp14> dispose of cached
tickets after some reasonable amount of time that mimics the session ticket
encryption key rotation period. Specifically, as specified in <xref
target="RFC8446" sectionFormat="of" section="4.6.1" format="default"/>,
clients <bcp14>MUST NOT</bcp14> cache tickets for longer than 7 days.</t>
</section> <t>
In some cases, a server may send NewSessionTicket messages immediately upon
<section title="Security Considerations" anchor="sect-6"><t> sending the server Finished message rather than waiting for the client
Ticket re-use is a security and privacy concern. Moreover, clients Finished message. If the server has not verified the client's ownership of i
must take care when pooling tickets as a means of avoiding or ts IP
amortizing handshake costs. If servers do not rotate session ticket address, e.g., with the TLS cookie extension (see <xref target="RFC8446"
encryption keys frequently, clients may be encouraged to obtain and sectionFormat="of" section="4.2.2" format="default"/>), an attacker may
use tickets beyond common lifetime windows of, e.g., 24 hours. take advantage of this behavior to create an amplification attack
Despite ticket lifetime hints provided by servers, clients SHOULD proportional to the count value toward a target by performing a (DTLS) key
dispose of cached tickets after some reasonable amount of time that exchange over UDP with spoofed packets. Servers <bcp14>SHOULD</bcp14>
mimics the session ticket encryption key rotation period. limit the number of NewSessionTicket messages they send until they have
Specifically, as specified in Section 4.6.1 of <xref target="RFC8446"/>, clie verified the client's ownership of its IP address.</t>
nts <t>
MUST NOT cache tickets for longer than 7 days.</t>
<t>
In some cases, a server may send NewSessionTicket messages
immediately upon sending the server Finished message rather than
waiting for the client Finished. If the server has not verified the
client's ownership of its IP address, e.g., with the TLS Cookie
extension (see <xref target="RFC8446"/>; Section 4.2.2), an attacker may take
advantage of this behavior to create an amplification attack
proportional to the count value toward a target by performing a
(DTLS) key exchange over UDP with spoofed packets. Servers SHOULD
limit the number of NewSessionTicket messages they send until they
have verified the client's ownership of its IP address.</t>
<t>
Servers that do not enforce a limit on the number of NewSessionTicket Servers that do not enforce a limit on the number of NewSessionTicket
messages sent in response to a "ticket_request" extension could leave messages sent in response to a "ticket_request" extension could leave
themselves open to DoS attacks, especially if ticket creation is themselves open to DoS attacks, especially if ticket creation is
expensive.</t> expensive.</t>
</section>
</section> </middle>
<back>
<section title="Acknowledgments" anchor="sect-7"><t> <displayreference target="I-D.ietf-taps-impl" to="TAPS"/>
The authors would like to thank David Benjamin, Eric Rescorla, Nick
Sullivan, Martin Thomson, Hubert Kario, and other members of the TLS
Working Group for discussions on earlier versions of this draft.
Viktor Dukhovni contributed text allowing clients to send multiple
counts in a ticket request.</t>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
</middle> <!-- [I-D.ietf-tls-dtls13] companion document RFC-to-be 9147 -->
<back> <reference anchor='RFC9147'>
<references title="Normative References"> <front>
&I-D.ietf-tls-dtls13; <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
&RFC2119;
&RFC8174;
&RFC8446;
</references>
<references title="Informative References">
&RFC8305;
&I-D.ietf-taps-impl;
</references>
</back>
</rfc> <author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
<organization />
</author>
<date month='August' year='2021' />
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8447.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8305.xml"/>
<!-- [I-D.ietf-taps-impl] IESG state I-D Exists -->
<reference anchor='I-D.ietf-taps-impl'>
<front>
<title>Implementing Interfaces to Transport Services</title>
<author initials='A' surname='Brunstrom' fullname='Anna Brunstrom' role="editor"
>
<organization />
</author>
<author initials='T' surname='Pauly' fullname='Tommy Pauly' role="editor">
<organization />
</author>
<author initials='T' surname='Enghardt' fullname='Theresa Enghardt'>
<organization />
</author>
<author initials='K-J' surname='Grinnemo' fullname='Karl-Johan Grinnemo'>
<organization />
</author>
<author initials='T' surname='Jones' fullname='Tom Jones'>
<organization />
</author>
<author initials='P' surname='Tiesel' fullname='Philipp Tiesel'>
<organization />
</author>
<author initials='C' surname='Perkins' fullname='Colin Perkins'>
<organization />
</author>
<author initials='M' surname='Welzl' fullname='Michael Welzl'>
<organization />
</author>
<date month='July' day='12' year='2021' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-taps-impl-10' />
</reference>
</references>
</references>
<section anchor="sect-7" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors would like to thank <contact fullname="David Benjamin"/>,
<contact fullname="Eric Rescorla"/>, <contact fullname="Nick Sullivan"/>,
<contact fullname="Martin Thomson"/>, <contact fullname="Hubert Kario"/>,
and other members of the TLS Working Group for discussions on earlier draft
versions of this document. <contact fullname="Viktor Dukhovni"/>
contributed text allowing clients to send multiple counts in a ticket
request.</t>
</section>
</back>
</rfc>
 End of changes. 59 change blocks. 
270 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/