draft-ietf-tls-ticketrequests-00.txt   draft-ietf-tls-ticketrequests-01.txt 
Network Working Group T. Pauly Network Working Group T. Pauly
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational D. Schinazi Intended status: Informational D. Schinazi
Expires: July 22, 2019 Google LLC Expires: December 8, 2019 Google LLC
C. Wood C. Wood
Apple Inc. Apple Inc.
January 18, 2019 June 06, 2019
TLS Ticket Requests TLS Ticket Requests
draft-ietf-tls-ticketrequests-00 draft-ietf-tls-ticketrequests-01
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 session clients without server-side, per-client state. Servers vend an
tickets to clients, at their discretion, upon connection arbitrary number of session tickets to clients, at their discretion,
establishment. Clients store and use tickets when resuming future upon connection establishment. Clients store and use tickets when
connections. Moreover, clients should use tickets at most once for resuming future connections. This document describes a mechanism by
session resumption, especially if such keying material protects early which clients may specify the desired number of tickets needed for
application data. Single-use tickets bound the number of parallel future connections. This extension aims to provide a means for
connections a client may initiate by the number of tickets received servers to determine the number of tickets to generate in order to
from a given server. To address this limitation, this document reduce ticket waste, while simultaneously priming clients for future
describes a mechanism by which clients may specify the desired number connection attempts.
of tickets needed for future connections.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 22, 2019. This Internet-Draft will expire on December 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 3 3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
As per [RFC5077], and as described in [RFC8446], TLS servers send As per [RFC5077], and as described in [RFC8446], TLS servers send
clients session tickets at their own discretion in NewSessionTicket clients an arbitrary number of session tickets at their own
messages. Clients are in complete control of how many tickets they discretion in NewSessionTicket messages. There are two limitations
may use when establishing future and subsequent connections. For with this design. First, servers choose some (often hard-coded)
example, clients may open multiple TLS connections to the same server number of tickets vended per connection. Second, clients do not have
for HTTP, or may race TLS connections across different network a way of expressing their desired number of tickets, which may impact
interfaces. The latter is especially useful in transport systems future connection establishment. For example, clients may open
that implement Happy Eyeballs [RFC8305]. Since connection multiple TLS connections to the same server for HTTP, or may race TLS
concurrency and resumption is controlled by clients, a standard connections across different network interfaces. The latter is
mechanism to request more than one ticket is desirable. 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.
This document specifies a new TLS extension - ticket_request - that This document specifies a new TLS extension - "ticket_request" - that
may be used by clients to express their desired number of session may be used by clients to express their desired number of session
tickets. Servers may use this extension as a hint of the number of tickets. Servers may use this extension as a hint of 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] and future versions of TLS. to TLS 1.3 [RFC8446], DTLS 1.3 [I-D.ietf-tls-dtls13], and future
versions thereof.
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, [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here. as shown here.
2. Use Cases 2. Use Cases
skipping to change at page 4, line 27 skipping to change at page 4, line 37
tickets they are willing to vend to clients. Thus, the number of tickets they are willing to vend to clients. Thus, the number of
NewSessionTicket messages sent should be the minimum of the server's NewSessionTicket messages sent should be the minimum of the server's
self-imposed limit and TicketRequestContents.count. Servers MUST NOT self-imposed limit and TicketRequestContents.count. Servers MUST NOT
send more than 255 tickets to clients. send more than 255 tickets to clients.
Servers that support ticket requests MUST NOT echo "ticket_request" Servers that support ticket requests MUST NOT echo "ticket_request"
in the EncryptedExtensions. in the EncryptedExtensions.
4. IANA Considerations 4. IANA Considerations
IANA is requested to Create an entry, ticket_requests(TBD), in the IANA is requested to Create an entry, ticket_request(TBD), in the
existing registry for ExtensionType (defined in [RFC8446]), with "TLS existing registry for ExtensionType (defined in [RFC8446]), with "TLS
1.3" column values being set to "CH", and "Recommended" column being 1.3" column values being set to "CH", and "Recommended" column being
set to "Yes". set to "Yes".
5. Security Considerations 5. Security Considerations
Ticket re-use is a security and privacy concern. Moreover, ticket Ticket re-use is a security and privacy concern. Moreover, clients
pooling as a means of avoiding or amortizing handshake costs must be must take care when pooling tickets as a means of avoiding or
used carefully. If servers do not rotate session ticket encryption amortizing handshake costs. If servers do not rotate session ticket
keys frequently, clients may be encouraged to obtain and use tickets encryption keys frequently, clients may be encouraged to obtain and
beyond common lifetime windows of, e.g., 24 hours. Despite ticket use tickets beyond common lifetime windows of, e.g., 24 hours.
lifetime hints provided by servers, clients SHOULD dispose of pooled Despite ticket lifetime hints provided by servers, clients SHOULD
tickets after some reasonable amount of time that mimics the ticket dispose of pooled tickets after some reasonable amount of time that
rotation period. mimics the ticket rotation period.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank David Benjamin, Eric Rescorla, Nick The authors would like to thank David Benjamin, Eric Rescorla, Nick
Sullivan, and Martin Thomson for discussions on earlier versions of Sullivan, Martin Thomson, and other members of the TLS Working Group
this draft. for discussions on earlier versions of this draft.
7. Normative References 7. Normative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", draft- "Implementing Interfaces to Transport Services", draft-
ietf-taps-impl-02 (work in progress), October 2018. ietf-taps-impl-03 (work in progress), March 2019.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-31 (work in progress), March
2019.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
 End of changes. 15 change blocks. 
40 lines changed or deleted 49 lines changed or added

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