idnits 2.17.1 draft-ietf-tls-ticketrequests-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 06, 2019) is 1776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-03 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational D. Schinazi 5 Expires: December 8, 2019 Google LLC 6 C. Wood 7 Apple Inc. 8 June 06, 2019 10 TLS Ticket Requests 11 draft-ietf-tls-ticketrequests-01 13 Abstract 15 TLS session tickets enable stateless connection resumption for 16 clients without server-side, per-client state. Servers vend an 17 arbitrary number of session tickets to clients, at their discretion, 18 upon connection establishment. Clients store and use tickets when 19 resuming future connections. This document describes a mechanism by 20 which clients may specify the desired number of tickets needed for 21 future connections. This extension aims to provide a means for 22 servers to determine the number of tickets to generate in order to 23 reduce ticket waste, while simultaneously priming clients for future 24 connection attempts. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 8, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 As per [RFC5077], and as described in [RFC8446], TLS servers send 73 clients an arbitrary number of session tickets at their own 74 discretion in NewSessionTicket messages. There are two limitations 75 with this design. First, servers choose some (often hard-coded) 76 number of tickets vended per connection. Second, clients do not have 77 a way of expressing their desired number of tickets, which may impact 78 future connection establishment. For example, clients may open 79 multiple TLS connections to the same server for HTTP, or may race TLS 80 connections across different network interfaces. The latter is 81 especially useful in transport systems that implement Happy Eyeballs 82 [RFC8305]. Since clients control connection concurrency and 83 resumption, a standard mechanism for requesting more than one ticket 84 is desirable. 86 This document specifies a new TLS extension - "ticket_request" - that 87 may be used by clients to express their desired number of session 88 tickets. Servers may use this extension as a hint of the number of 89 NewSessionTicket messages to vend. This extension is only applicable 90 to TLS 1.3 [RFC8446], DTLS 1.3 [I-D.ietf-tls-dtls13], and future 91 versions thereof. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 99 as shown here. 101 2. Use Cases 103 The ability to request one or more tickets is useful for a variety of 104 purposes: 106 o Parallel HTTP connections: To minimize ticket reuse while still 107 improving performance, it may be useful to use multiple, distinct 108 tickets when opening parallel connections. Clients must therefore 109 bound the number of parallel connections they initiate by the 110 number of tickets in their possession, or risk ticket re-use. 112 o Connection racing: Happy Eyeballs V2 [RFC8305] describes 113 techniques for performing connection racing. The Transport 114 Services Architecture implementation from [I-D.ietf-taps-impl] 115 also describes how connections may race across interfaces and 116 address families. In cases where clients have early data to send 117 and want to minimize or avoid ticket re-use, unique tickets for 118 each unique connection attempt are useful. Moreover, as some 119 servers may implement single-use tickets (and even session ticket 120 encryption keys), distinct tickets will be needed to prevent 121 premature ticket invalidation by racing. 123 o Connection priming: In some systems, connections may be primed or 124 bootstrapped by a centralized service or daemon for faster 125 connection establishment. Requesting tickets on demand allows 126 such services to vend tickets to clients to use for accelerated 127 handshakes with early data. (Note that if early data is not 128 needed by these connections, this method SHOULD NOT be used. 129 Fresh handshakes SHOULD be performed instead.) 131 o Less ticket waste: Currently, TLS servers use application- 132 specific, and often implementation-specific, logic to determine 133 how many tickets to issue. By moving the burden of ticket count 134 to clients, servers do not generate wasteful tickets for clients. 135 Moreover, as ticket generation may involve expensive computation, 136 e.g., public key cryptographic operations, avoiding waste is 137 desirable. 139 3. Ticket Requests 141 Clients may indicate to servers their desired number of tickets via 142 the following "ticket_request" extension: 144 enum { 145 ticket_request(TBD), (65535) 146 } ExtensionType; 148 Clients may send this extension in ClientHello. It contains the 149 following structure: 151 struct { 152 uint8 count; 153 } TicketRequestContents; 155 count The number of tickets desired by the client. 157 A supporting server MAY vend TicketRequestContents.count 158 NewSessionTicket messages to a requesting client, and SHOULD NOT send 159 more than TicketRequestContents.count NewSessionTicket messages to a 160 requesting client. Servers SHOULD place a limit on the number of 161 tickets they are willing to vend to clients. Thus, the number of 162 NewSessionTicket messages sent should be the minimum of the server's 163 self-imposed limit and TicketRequestContents.count. Servers MUST NOT 164 send more than 255 tickets to clients. 166 Servers that support ticket requests MUST NOT echo "ticket_request" 167 in the EncryptedExtensions. 169 4. IANA Considerations 171 IANA is requested to Create an entry, ticket_request(TBD), in the 172 existing registry for ExtensionType (defined in [RFC8446]), with "TLS 173 1.3" column values being set to "CH", and "Recommended" column being 174 set to "Yes". 176 5. Security Considerations 178 Ticket re-use is a security and privacy concern. Moreover, clients 179 must take care when pooling tickets as a means of avoiding or 180 amortizing handshake costs. If servers do not rotate session ticket 181 encryption keys frequently, clients may be encouraged to obtain and 182 use tickets beyond common lifetime windows of, e.g., 24 hours. 183 Despite ticket lifetime hints provided by servers, clients SHOULD 184 dispose of pooled tickets after some reasonable amount of time that 185 mimics the ticket rotation period. 187 6. Acknowledgments 189 The authors would like to thank David Benjamin, Eric Rescorla, Nick 190 Sullivan, Martin Thomson, and other members of the TLS Working Group 191 for discussions on earlier versions of this draft. 193 7. Normative References 195 [I-D.ietf-taps-impl] 196 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 197 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 198 "Implementing Interfaces to Transport Services", draft- 199 ietf-taps-impl-03 (work in progress), March 2019. 201 [I-D.ietf-tls-dtls13] 202 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 203 Datagram Transport Layer Security (DTLS) Protocol Version 204 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 205 2019. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, . 212 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 213 "Transport Layer Security (TLS) Session Resumption without 214 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 215 January 2008, . 217 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 218 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 219 May 2017, . 221 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 222 Better Connectivity Using Concurrency", RFC 8305, 223 DOI 10.17487/RFC8305, December 2017, . 226 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 227 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 228 . 230 Authors' Addresses 231 Tommy Pauly 232 Apple Inc. 233 One Apple Park Way 234 Cupertino, California 95014 235 United States of America 237 Email: tpauly@apple.com 239 David Schinazi 240 Google LLC 241 1600 Amphitheatre Parkway 242 Mountain View, California 94043 243 United States of America 245 Email: dschinazi.ietf@gmail.com 247 Christopher A. Wood 248 Apple Inc. 249 One Apple Park Way 250 Cupertino, California 95014 251 United States of America 253 Email: cawood@apple.com