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