rfc9149.original   rfc9149.txt 
Network Working Group T. Pauly Internet Engineering Task Force (IETF) T. Pauly
Internet-Draft Apple Inc. Request for Comments: 9149 Apple Inc.
Intended status: Standards Track D. Schinazi Category: Standards Track D. Schinazi
Expires: 6 June 2021 Google LLC ISSN: 2070-1721 Google LLC
C.A. Wood C.A. Wood
Cloudflare Cloudflare
3 December 2020 August 2021
TLS Ticket Requests TLS Ticket Requests
draft-ietf-tls-ticketrequests-07
Abstract Abstract
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. connection attempts.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/draft-ietf-tls-ticketrequest.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 June 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9149.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases
3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 4 3. Ticket Requests
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations
5. Performance Considerations . . . . . . . . . . . . . . . . . 6 5. Performance Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses
1. Introduction 1. Introduction
As as described in [RFC8446], TLS servers vend clients an arbitrary As described in [RFC8446], TLS servers vend clients an arbitrary
number of session tickets at their own discretion in NewSessionTicket number of session tickets at their own discretion in NewSessionTicket
messages. There are at least three limitations with this design. messages. There are at least three limitations with this design.
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 of tickets for session resumption than for the initial number of tickets for session resumption than for the initial
connection that created the session. No static choice, whether connection that created the session. No static choice, whether fixed
fixed, or resumption-dependent is ideal for all situations. or dependent upon resumption, is ideal for all situations.
Second, clients do not have a way of expressing their desired number Second, clients do not have a way of expressing their desired number
of tickets, which can impact future connection establishment. For of tickets, which can impact future connection establishment. For
example, clients can open parallel TLS connections to the same server example, clients can open parallel TLS connections to the same server
for HTTP, or race TLS connections across different network for HTTP, or they can race TLS connections across different network
interfaces. The latter is especially useful in transport systems interfaces. The latter is especially useful in transport systems
that implement Happy Eyeballs [RFC8305]. Since clients control that implement Happy Eyeballs [RFC8305]. Since clients control
connection concurrency and resumption, a standard mechanism for connection concurrency and resumption, a standard mechanism for
requesting more than one ticket is desirable for avoiding ticket requesting more than one ticket is desirable for avoiding ticket
reuse. See [RFC8446], Appendix C.4 for discussion of ticket reuse reuse. See Appendix C.4 of [RFC8446] for discussion of ticket reuse
risks. risks.
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. routine resumption.
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 Servers can use this extension as a hint for the number of
NewSessionTicket messages to vend. This extension is only applicable NewSessionTicket messages to vend. This extension is only applicable
to TLS 1.3 [RFC8446], DTLS 1.3 [I-D.ietf-tls-dtls13], and future to TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and future versions of
versions of (D)TLS. (D)TLS.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
as shown here. capitals, as shown here.
2. Use Cases 2. Use Cases
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: purposes:
* Parallel HTTP connections: To improve performance, a client may Parallel HTTP connections: To improve performance, a client may open
open parallel connections. To avoid ticket reuse, the client may parallel connections. To avoid ticket reuse, the client may use
use distinct tickets on each connection. Clients must therefore distinct tickets on each connection. Clients must therefore bound
bound the number of parallel connections they initiate by the the number of parallel connections they initiate by the number of
number of tickets in their possession, or risk ticket re-use. tickets in their possession or risk ticket reuse.
* Connection racing: Happy Eyeballs V2 [RFC8305] describes Connection racing: Happy Eyeballs V2 [RFC8305] describes techniques
techniques for performing connection racing. The Transport for performing connection racing. The Transport Services
Services Architecture implementation from [TAPS] also describes Implementation document [TAPS] also describes how connections can
how connections can race across interfaces and address families. race across interfaces and address families. In such cases,
In such cases, clients may use more than one ticket while racing clients may use more than one ticket while racing connection
connection attempts in order to establish one successful attempts in order to establish one successful connection. Having
connection. Having multiple tickets equips clients with enough multiple tickets equips clients with enough tickets to initiate
tickets to initiate connection racing while avoiding ticket re-use connection racing while avoiding ticket reuse and ensuring that
and ensuring that their cache of tickets does not empty during their cache of tickets does not empty during such races.
such races. Moreover, as some servers may implement single-use Moreover, as some servers may implement single-use tickets,
tickets, distinct tickets prevent premature ticket invalidation by distinct tickets prevent premature ticket invalidation by racing.
racing.
* Less ticket waste: Currently, TLS servers use application- Less ticket waste: Currently, TLS servers use application-specific,
specific, and often implementation-specific, logic to determine and often implementation-specific, logic to determine how many
how many tickets to issue. By moving the burden of ticket count tickets to issue. By moving the burden of ticket count to
to clients, servers do not generate wasteful tickets. As an clients, servers do not generate wasteful tickets. As an example,
example, clients might only request one ticket during resumption. clients might only request one ticket during resumption.
Moreover, as ticket generation might involve expensive Moreover, as ticket generation might involve expensive
computation, e.g., public key cryptographic operations, avoiding computation, e.g., public key cryptographic operations, avoiding
waste is desirable. waste is desirable.
* Decline resumption: Clients can indicate they do not intend to Decline resumption: Clients can indicate they do not intend to
resume a connection by sending a ticket request with count of resume a connection by sending a ticket request with count of
zero. zero.
3. Ticket Requests 3. Ticket Requests
As discussed in Section 1, clients may want different numbers of As discussed in Section 1, clients may want different 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: following "ticket_request" extension:
enum { enum {
ticket_request(TBD), (65535) ticket_request(58), (65535)
} ExtensionType; } ExtensionType;
Clients MAY send this extension in ClientHello. It contains the Clients MAY send this extension in ClientHello. It contains the
following structure: following structure:
struct { struct {
uint8 new_session_count; uint8 new_session_count;
uint8 resumption_count; uint8 resumption_count;
} ClientTicketRequest; } ClientTicketRequest;
new_session_count The number of tickets desired by the client if the new_session_count: The number of tickets desired by the client if
server chooses to negotiate a new connection. the server chooses to negotiate a new connection.
resumption_count The number of tickets desired by the client if the resumption_count: The number of tickets desired by the client if the
server is willing to resume using a ticket presented in this server is willing to resume using a ticket presented in this
ClientHello. ClientHello.
A client starting a new connection SHOULD set new_session_count to 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.) zero tickets.)
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 SHOULD
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. connection helps keep the session cache primed.
Servers SHOULD NOT 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 SHOULD place a limit on the number of tickets 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 MAY send additional tickets, typically
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. somehow invalidated.
A server which supports and uses a client "ticket_request" extension A server that supports and uses a client "ticket_request" extension
MUST also send the "ticket_request" extension in the MUST also send the "ticket_request" extension in the
EncryptedExtensions message. It contains the following structure: EncryptedExtensions message. It contains the following structure:
struct { struct {
uint8 expected_count; uint8 expected_count;
} ServerTicketRequestHint; } ServerTicketRequestHint;
expected_count The number of tickets the server expects to send in expected_count: The number of tickets the server expects to send in
this connection. this connection.
Servers MUST NOT send the "ticket_request" extension in any handshake 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 MUST abort the connection with an "illegal_parameter" alert if
the "ticket_request" extension is present in any server handshake the "ticket_request" extension is present in any server handshake
message. message.
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 MUST be maintained in the second
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 MUST NOT change the value of ClientTicketRequest in the second
ClientHello message. ClientHello message.
4. IANA Considerations 4. IANA Considerations
IANA is requested to create an entry, ticket_request(TBD), in the IANA has added the following entry to the "TLS ExtensionType Values"
existing registry for ExtensionType (defined in [RFC8446]), with "TLS registry [RFC8446] [RFC8447]:
1.3" column values being set to "CH, EE", and "Recommended" column
being set to "Y". +=======+================+=========+===========+=============+
| Value | Extension Name | TLS 1.3 | DTLS-Only | Recommended |
+=======+================+=========+===========+=============+
| 58 | ticket_request | CH, EE | N | Y |
+-------+----------------+---------+-----------+-------------+
Table 1: Addition to TLS ExtensionType Values Registry
5. Performance Considerations 5. Performance Considerations
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 [RFC8446]; Section 4.6.1). A server the server Finished message (see Section 4.6.1 of [RFC8446]). A
which chooses to send a large number of tickets to a client can server 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. sending application data over tickets when possible.
6. Security Considerations 6. Security Considerations
Ticket re-use is a security and privacy concern. Moreover, clients Ticket reuse is a security and privacy concern. Moreover, clients
must take care when pooling tickets as a means of avoiding or must take care when pooling tickets as a means of avoiding or
amortizing handshake costs. If servers do not rotate session ticket amortizing handshake costs. If servers do not rotate session ticket
encryption keys frequently, clients may be encouraged to obtain and encryption keys frequently, clients may be encouraged to obtain and
use tickets beyond common lifetime windows of, e.g., 24 hours. use tickets beyond common lifetime windows of, e.g., 24 hours.
Despite ticket lifetime hints provided by servers, clients SHOULD Despite ticket lifetime hints provided by servers, clients SHOULD
dispose of cached tickets after some reasonable amount of time that dispose of cached tickets after some reasonable amount of time that
mimics the session ticket encryption key rotation period. mimics the session ticket encryption key rotation period.
Specifically, as specified in Section 4.6.1 of [RFC8446], clients Specifically, as specified in Section 4.6.1 of [RFC8446], clients
MUST NOT cache tickets for longer than 7 days. MUST NOT cache tickets for longer than 7 days.
In some cases, a server may send NewSessionTicket messages In some cases, a server may send NewSessionTicket messages
immediately upon sending the server Finished message rather than immediately upon sending the server Finished message rather than
waiting for the client Finished. If the server has not verified the waiting for the client Finished message. If the server has not
client's ownership of its IP address, e.g., with the TLS Cookie verified the client's ownership of its IP address, e.g., with the TLS
extension (see [RFC8446]; Section 4.2.2), an attacker may take cookie extension (see Section 4.2.2 of [RFC8446]), an attacker may
advantage of this behavior to create an amplification attack take advantage of this behavior to create an amplification attack
proportional to the count value toward a target by performing a proportional to the count value toward a target by performing a
(DTLS) key exchange over UDP with spoofed packets. Servers SHOULD (DTLS) key exchange over UDP with spoofed packets. Servers SHOULD
limit the number of NewSessionTicket messages they send until they limit the number of NewSessionTicket messages they send until they
have verified the client's ownership of its IP address. have verified the client's ownership of its IP address.
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. expensive.
7. Acknowledgments 7. References
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.
8. References
8.1. Normative References
[I-D.ietf-tls-dtls13] 7.1. Normative References
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-39, 2 November 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-39.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, August 2021,
<https://www.rfc-editor.org/rfc/rfc9147>.
7.2. Informative References
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[TAPS] Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., [TAPS] Brunstrom, A., Ed., Pauly, T., Ed., Enghardt, T.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Grinnemo, K-J., Jones, T., Tiesel, P., Perkins, C., and M.
"Implementing Interfaces to Transport Services", Work in Welzl, "Implementing Interfaces to Transport Services",
Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 Work in Progress, Internet-Draft, draft-ietf-taps-impl-10,
November 2020, <http://www.ietf.org/internet-drafts/draft- 12 July 2021, <https://datatracker.ietf.org/doc/html/
ietf-taps-impl-08.txt>. draft-ietf-taps-impl-10>.
Acknowledgements
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 draft versions of this
document. Viktor Dukhovni contributed text allowing clients to send
multiple counts in a ticket request.
Authors' Addresses Authors' Addresses
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, CA 95014
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
David Schinazi David Schinazi
Google LLC Google LLC
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California 94043, Mountain View, CA 94043
United States of America United States of America
Email: dschinazi.ietf@gmail.com Email: dschinazi.ietf@gmail.com
Christopher A. Wood Christopher A. Wood
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco, San Francisco, CA 94107
United States of America United States of America
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 43 change blocks. 
129 lines changed or deleted 126 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/