idnits 2.17.00 (12 Aug 2021) /tmp/idnits23694/draft-wood-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 (October 13, 2018) is 1309 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-taps-impl-01 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 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 D. Schinazi 4 Intended status: Informational C. Wood 5 Expires: April 16, 2019 Apple Inc. 6 October 13, 2018 8 TLS Ticket Requests 9 draft-wood-tls-ticketrequests-01 11 Abstract 13 TLS session tickets enable stateless connection resumption for 14 clients without server-side per-client state. Servers vend session 15 tickets to clients, at their discretion, upon connection 16 establishment. Clients store and use tickets when resuming future 17 connections. Moreover, clients should use tickets at most once for 18 session resumption, especially if such keying material protects early 19 application data. Single-use tickets bound the number of parallel 20 connections a client may initiate by the number of tickets received 21 from a given server. To address this limitation, this document 22 describes a mechanism by which clients may specify the desired number 23 of tickets needed for future connections. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 16, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 61 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Ticket Requests . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 As per [RFC5077], and as described in [RFC8446], TLS servers send 72 clients session tickets at their own discretion in NewSessionTicket 73 messages. Clients are in complete control of how many tickets they 74 may use when establishing future and subsequent connections. For 75 example, clients may open multiple TLS connections to the same server 76 for HTTP, or may race TLS connections across different network 77 interfaces. The latter is especially useful in transport systems 78 that implement Happy Eyeballs [RFC8305]. Since connection 79 concurrency and resumption is controlled by clients, a standard 80 mechanism to request more than one ticket is desirable. 82 This document specifies a new TLS extension - ticket_request - that 83 may be used by clients to express their desired number of session 84 tickets. Servers may use this extension as a hint of the number of 85 NewSessionTicket messages to vend. This extension is only applicable 86 to TLS 1.3 [RFC8446] and future versions of TLS. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 94 as shown here. 96 2. Use Cases 98 The ability to request one or more tickets is useful for a variety of 99 purposes: 101 o Parallel HTTP connections: To minimize ticket reuse while still 102 improving performance, it may be useful to use multiple, distinct 103 tickets when opening parallel connections. Clients must therefore 104 bound the number of parallel connections they initiate by the 105 number of tickets in their possession, or risk ticket re-use. 107 o Connection racing: Happy Eyeballs V2 [RFC8305] describes 108 techniques for performing connection racing. The Transport 109 Services Architecture implementation from [I-D.ietf-taps-impl] 110 also describes how connections may race across interfaces and 111 address families. In cases where clients have early data to send 112 and want to minimize or avoid ticket re-use, unique tickets for 113 each unique connection attempt are useful. Moreover, as some 114 servers may implement single-use tickets (and even session ticket 115 encryption keys), distinct tickets will be needed to prevent 116 premature ticket invalidation by racing. 118 o Connection priming: In some systems, connections may be primed or 119 bootstrapped by a centralized service or daemon for faster 120 connection establishment. Requesting tickets on demand allows 121 such services to vend tickets to clients to use for accelerated 122 handshakes with early data. (Note that if early data is not 123 needed by these connections, this method SHOULD NOT be used. 124 Fresh handshakes SHOULD be performed instead.) 126 o Less ticket waste: Currently, TLS servers use application- 127 specific, and often implementation-specific, logic to determine 128 how many tickets to issue. By moving the burden of ticket count 129 to clients, servers do not generate wasteful tickets for clients. 130 Moreover, as ticket generation may involve expensive computation, 131 e.g., public key cryptographic operations, avoiding waste is 132 desirable. 134 3. Ticket Requests 136 Clients may indicate to servers their desired number of tickets via 137 the following "ticket_request" extension: 139 enum { 140 ticket_request(TBD), (65535) 141 } ExtensionType; 142 Clients may send this extension in ClientHello. It contains the 143 following structure: 145 struct { 146 uint8 count; 147 } TicketRequestContents; 149 count The number of tickets desired by the client. 151 A supporting server MAY vend TicketRequestContents.count 152 NewSessionTicket messages to a requesting client, and SHOULD NOT send 153 more than TicketRequestContents.count NewSessionTicket messages to a 154 requesting client. Servers SHOULD place a limit on the number of 155 tickets they are willing to vend to clients. Thus, the number of 156 NewSessionTicket messages sent should be the minimum of the server's 157 self-imposed limit and TicketRequestContents.count. Servers MUST NOT 158 send more than 255 tickets to clients. 160 Servers that support ticket requests MUST NOT echo "ticket_request" 161 in the EncryptedExtensions. 163 4. IANA Considerations 165 IANA is requested to Create an entry, ticket_requests(TBD), in the 166 existing registry for ExtensionType (defined in [RFC8446]), with "TLS 167 1.3" column values being set to "CH", and "Recommended" column being 168 set to "Yes". 170 5. Security Considerations 172 Ticket re-use is a security and privacy concern. Moreover, ticket 173 pooling as a means of avoiding or amortizing handshake costs must be 174 used carefully. If servers do not rotate session ticket encryption 175 keys frequently, clients may be encouraged to obtain and use tickets 176 beyond common lifetime windows of, e.g., 24 hours. Despite ticket 177 lifetime hints provided by servers, clients SHOULD dispose of pooled 178 tickets after some reasonable amount of time that mimics the ticket 179 rotation period. 181 6. Acknowledgments 183 The authors would like to thank David Benjamin, Eric Rescorla, Nick 184 Sullivan, and Martin Thomson for discussions on earlier versions of 185 this draft. 187 7. Normative References 189 [I-D.ietf-taps-impl] 190 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 191 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 192 "Implementing Interfaces to Transport Services", draft- 193 ietf-taps-impl-01 (work in progress), July 2018. 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, . 200 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 201 "Transport Layer Security (TLS) Session Resumption without 202 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 203 January 2008, . 205 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 206 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 207 May 2017, . 209 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 210 Better Connectivity Using Concurrency", RFC 8305, 211 DOI 10.17487/RFC8305, December 2017, . 214 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 215 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 216 . 218 Authors' Addresses 220 Tommy Pauly 221 Apple Inc. 222 One Apple Park Way 223 Cupertino, California 95014 224 United States of America 226 Email: tpauly@apple.com 227 David Schinazi 228 Apple Inc. 229 One Apple Park Way 230 Cupertino, California 95014 231 United States of America 233 Email: dschinazi@apple.com 235 Christopher A. Wood 236 Apple Inc. 237 One Apple Park Way 238 Cupertino, California 95014 239 United States of America 241 Email: cawood@apple.com