idnits 2.17.1 draft-ietf-tls-ticketrequests-06.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 (19 November 2020) is 1247 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-39 == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-08 Summary: 0 errors (**), 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: Standards Track D. Schinazi 5 Expires: 23 May 2021 Google LLC 6 C.A. Wood 7 Cloudflare 8 19 November 2020 10 TLS Ticket Requests 11 draft-ietf-tls-ticketrequests-06 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 can 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 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/tlswg/draft-ietf-tls-ticketrequest. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 23 May 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 5. Performance Considerations . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 As as described in [RFC8446], TLS servers vend clients an arbitrary 82 number of session tickets at their own discretion in NewSessionTicket 83 messages. There are at least three limitations with this design. 85 First, servers vend some (often hard-coded) number of tickets per 86 connection. Some server implementations return a different default 87 number of tickets for session resumption than for the initial 88 connection that created the session. No static choice, whether 89 fixed, or resumption-dependent is ideal for all situations. 91 Second, clients do not have a way of expressing their desired number 92 of tickets, which can impact future connection establishment. For 93 example, clients can open parallel TLS connections to the same server 94 for HTTP, or race TLS connections across different network 95 interfaces. The latter is especially useful in transport systems 96 that implement Happy Eyeballs [RFC8305]. Since clients control 97 connection concurrency and resumption, a standard mechanism for 98 requesting more than one ticket is desirable for avoiding ticket 99 reuse. See [RFC8446], Appendix C.4 for discussion of ticket reuse 100 risks. 102 Third, all tickets in the client's possession ultimately derive from 103 some initial connection. Especially when the client was initially 104 authenticated with a client certificate, that session may need to be 105 refreshed from time to time. Consequently, a server may periodically 106 force a new connection even when the client presents a valid ticket. 107 When that happens, it is possible that any other tickets derived from 108 the same original session are equally invalid. A client avoids a 109 full handshake on subsequent connections if it replaces all stored 110 tickets with new ones obtained from the just performed full 111 handshake. The number of tickets the server should vend for a new 112 connection may therefore need to be larger than the number for 113 routine resumption. 115 This document specifies a new TLS extension - "ticket_request" - that 116 clients can use to express their desired number of session tickets. 117 Servers can use this extension as a hint for the number of 118 NewSessionTicket messages to vend. This extension is only applicable 119 to TLS 1.3 [RFC8446], DTLS 1.3 [I-D.ietf-tls-dtls13], and future 120 versions of (D)TLS. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 128 as shown here. 130 2. Use Cases 132 The ability to request one or more tickets is useful for a variety of 133 purposes: 135 * Parallel HTTP connections: To minimize ticket reuse while still 136 improving performance, it may be useful to use multiple, distinct 137 tickets when opening parallel connections. Clients must therefore 138 bound the number of parallel connections they initiate by the 139 number of tickets in their possession, or risk ticket re-use. 141 * Connection racing: Happy Eyeballs V2 [RFC8305] describes 142 techniques for performing connection racing. The Transport 143 Services Architecture implementation from [TAPS] also describes 144 how connections can race across interfaces and address families. 145 In such cases, clients may use more than one ticket while racing 146 connection attempts in order to establish one successful 147 connection. Having multiple tickets equips clients with enough 148 tickets to initiate connection racing while avoiding ticket re-use 149 and ensuring that their cache of tickets does not empty during 150 such races. Moreover, as some servers may implement single-use 151 tickets, distinct tickets prevent premature ticket invalidation by 152 racing. 154 * Less ticket waste: Currently, TLS servers use application- 155 specific, and often implementation-specific, logic to determine 156 how many tickets to issue. By moving the burden of ticket count 157 to clients, servers do not generate wasteful tickets. As an 158 example, clients might only request one ticket during resumption. 159 Moreover, as ticket generation might involve expensive 160 computation, e.g., public key cryptographic operations, avoiding 161 waste is desirable. 163 * Decline resumption: Clients can indicate they have no intention of 164 resuming connections by sending a ticket request with count of 165 zero. 167 3. Ticket Requests 169 As discussed in Section 1, clients may want different numbers of 170 tickets for new or resumed connections. Clients may indicate to 171 servers their desired number of tickets to receive on a single 172 connection, in the case of a new or resumed connection, via the 173 following "ticket_request" extension: 175 enum { 176 ticket_request(TBD), (65535) 177 } ExtensionType; 179 Clients MAY send this extension in ClientHello. It contains the 180 following structure: 182 struct { 183 uint8 new_session_count; 184 uint8 resumption_count; 185 } ClientTicketRequest; 187 new_session_count The number of tickets desired by the client when 188 the server chooses to negotiate a new connection. 190 resumption_count The number of tickets desired by the client when 191 the server is willing to resume using a ticket presented in this 192 ClientHello. 194 A client starting a new connection SHOULD set new_session_count to 195 the desired number of session tickets and resumption_count to 0. 196 Once a client's ticket cache is primed, a resumption_count of 1 is a 197 good choice that allows the server to replace each ticket with a new 198 ticket, without over-provisioning the client with excess tickets. 199 However, clients which race multiple connections and place a separate 200 ticket in each will ultimately end up with just the tickets from a 201 single resumed session. In that case, clients can send a 202 resumption_count equal to the number of sessions they are attempting 203 in parallel. (Clients which send a resumption_count less than the 204 number of parallel connection attempts might end up with zero 205 tickets.) 207 When a client presenting a previously obtained ticket finds that the 208 server nevertheless negotiates a new connection, the client SHOULD 209 assume that any other tickets associated with the same session as the 210 presented ticket are also no longer valid for resumption. This 211 includes tickets obtained during the initial (new) connection and all 212 tickets subsequently obtained as part of subsequent resumptions. 213 Requesting more than one ticket in cases when servers complete a new 214 connection helps keep the session cache primed. 216 Servers SHOULD NOT send more tickets than requested for the 217 connection type selected by the server (new or resumed connection). 218 Moreover, servers SHOULD place a limit on the number of tickets they 219 are willing to send, whether for new or resumed connections, to save 220 resources. Therefore, the number of NewSessionTicket messages sent 221 will typically be the minimum of the server's self-imposed limit and 222 the number requested. Servers MAY send additional tickets, typically 223 using the same limit, if the tickets that are originally sent are 224 somehow invalidated. 226 A server which supports and uses a client "ticket_request" extension 227 MUST also send the "ticket_request" extension in the 228 EncryptedExtensions message. It contains the following structure: 230 struct { 231 uint8 expected_count; 232 } ServerTicketRequestHint; 234 expected_count The number of tickets the server expects to send in 235 this connection. 237 Servers MUST NOT send the "ticket_request" extension in any handshake 238 message, including ServerHello or HelloRetryRequest messages. A 239 client MUST abort the connection with an "illegal_parameter" alert if 240 the "ticket_request" extension is present in any server handshake 241 message. 243 If a client receives a HelloRetryRequest, the presence (or absence) 244 of the "ticket_request" extension MUST be maintained in the second 245 ClientHello message. Moreover, if this extension is present, a 246 client MUST NOT change the value of ClientTicketRequest in the second 247 ClientHello message. 249 4. IANA Considerations 251 IANA is requested to create an entry, ticket_request(TBD), in the 252 existing registry for ExtensionType (defined in [RFC8446]), with "TLS 253 1.3" column values being set to "CH, EE", and "Recommended" column 254 being set to "Y". 256 5. Performance Considerations 258 Servers can send tickets in NewSessionTicket messages any time after 259 the server Finished message (see [RFC8446]; Section 4.6.1). A server 260 which chooses to send a large number of tickets to a client can 261 potentially harm application performance if the tickets are sent 262 before application data. For example, if the transport connection 263 has a constrained congestion window, ticket messages could delay 264 sending application data. To avoid this, servers should prioritize 265 sending application data over tickets when possible. 267 6. Security Considerations 269 Ticket re-use is a security and privacy concern. Moreover, clients 270 must take care when pooling tickets as a means of avoiding or 271 amortizing handshake costs. If servers do not rotate session ticket 272 encryption keys frequently, clients may be encouraged to obtain and 273 use tickets beyond common lifetime windows of, e.g., 24 hours. 274 Despite ticket lifetime hints provided by servers, clients SHOULD 275 dispose of cached tickets after some reasonable amount of time that 276 mimics the session ticket encryption key rotation period. 277 Specifically, as specified in Section 4.6.1 of [RFC8446], clients 278 MUST NOT cache tickets for longer than 7 days. 280 In some cases, a server may send NewSessionTicket messages 281 immediately upon sending the server Finished message rather than 282 waiting for the client Finished. If the server has not verified the 283 client's ownership of its IP address, e.g., with the TLS Cookie 284 extension (see [RFC8446]; Section 4.2.2), an attacker may take 285 advantage of this behavior to create an amplification attack 286 proportional to the count value toward a target by performing a 287 (DTLS) key exchange over UDP with spoofed packets. Servers SHOULD 288 limit the number of NewSessionTicket messages they send until they 289 have verified the client's ownership of its IP address. 291 Servers that do not enforce a limit on the number of NewSessionTicket 292 messages sent in response to a "ticket_request" extension could leave 293 themselves open to DoS attacks, especially if ticket creation is 294 expensive. 296 7. Acknowledgments 298 The authors would like to thank David Benjamin, Eric Rescorla, Nick 299 Sullivan, Martin Thomson, Hubert Kario, and other members of the TLS 300 Working Group for discussions on earlier versions of this draft. 301 Viktor Dukhovni contributed text allowing clients to send multiple 302 counts in a ticket request. 304 8. References 306 8.1. Normative References 308 [I-D.ietf-tls-dtls13] 309 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 310 Datagram Transport Layer Security (DTLS) Protocol Version 311 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 312 dtls13-39, 2 November 2020, . 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 325 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 326 . 328 8.2. Informative References 330 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 331 Better Connectivity Using Concurrency", RFC 8305, 332 DOI 10.17487/RFC8305, December 2017, 333 . 335 [TAPS] Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 336 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 337 "Implementing Interfaces to Transport Services", Work in 338 Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 339 November 2020, . 342 Authors' Addresses 344 Tommy Pauly 345 Apple Inc. 346 One Apple Park Way 347 Cupertino, California 95014, 348 United States of America 350 Email: tpauly@apple.com 352 David Schinazi 353 Google LLC 354 1600 Amphitheatre Parkway 355 Mountain View, California 94043, 356 United States of America 358 Email: dschinazi.ietf@gmail.com 360 Christopher A. Wood 361 Cloudflare 362 101 Townsend St 363 San Francisco, 364 United States of America 366 Email: caw@heapingbits.net