idnits 2.17.1 draft-sy-tls-resumption-group-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 (March 01, 2019) is 1854 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls E. Sy 3 Internet-Draft University of Hamburg 4 Intended status: Experimental March 01, 2019 5 Expires: September 2, 2019 7 TLS Resumption across Server Name Indications for TLS 1.3 8 draft-sy-tls-resumption-group-00 10 Abstract 12 This document defines a mechanism for resuming a TLS 1.3 session 13 across different Server Name Indications. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 2, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 51 3. Overview on Resumptions across SNI values . . . . . . . . . . 3 52 4. The "resumption_group" Extension . . . . . . . . . . . . . . 3 53 4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 3 54 4.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 55 5. Expectations on Certificates . . . . . . . . . . . . . . . . 5 56 6. Compatibility Issues with Middleboxes . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 9.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Most web transactions are short transfers that are significantly 68 delayed by the TLS connection establishment. To accelerate the 69 connection establishment, TLS 1.3 [RFC8446] and its predecessors 70 provide session resumption mechanisms. They abbreviate the TLS 71 handshake based on a shared secret exchanged during a prior TLS 72 session between client and server. In total, these resumption 73 handshakes significantly reduce computational overhead for 74 cryptographic operations and save up to one round-trip compared to 75 the full TLS connection establishment. 77 TLS 1.3 [RFC8446] allows resumption handshakes across Server Name 78 Indications (SNIs) when they share the same TLS certificate. 79 However, TLS 1.3 recommends not to use TLS resumptions across SNIs to 80 avoid loosing a single-use ticket in case of a failed resumption 81 attempt. This practice requires costly full TLS connection 82 establishments in situations where a performance-optimized resumption 83 handshake across SNI values would be possible. To illustrate this 84 performance limitation, we describe the common situation of a 85 redirected web request. We assume that the hostname example.com 86 redirects to www.example.com and both hostnames are operated by the 87 same entity and use the same certificate for their authentication. A 88 client requesting www.example.com via this redirect requires two full 89 TLS handshakes following the recommendation of TLS 1.3 [RFC8446]. 90 Using resumption across SNI values, the later full handshake can be 91 converted to a performance-optimized resumed handshake. A 92 comprehensive study of the performance benefits of resumptions across 93 SNI values for popular websites can be found in [PERF]. 95 This document defines a mechanism to inform the client in between 96 which SNI values TLS resumptions are supported. This information 97 enables the client to use resumption across SNI values only in 98 situations where the chance of a successful resumption handshake is 99 high. 101 2. Conventions and Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Overview on Resumptions across SNI values 111 When a client wants to form a TLS connection to a server, it 112 indicates support for the "resumption_group" extension in the 113 ClientHello message. To signal its support for this extension type, 114 the server returns the "resumption_group" extension with an empty 115 data field. 117 The client is now aware, that all SNI values for which the presented 118 server certificate is valid, form a TLS resumption group. Thus, 119 resumption tickets issued by a group member are designated to be used 120 to establish resumed connections to any member of the same group. 122 4. The "resumption_group" Extension 124 This extension carries no data as defined in the following 125 ResumptionGroup structure: 127 struct { 128 } ResumptionGroup; 130 4.1. Client Behavior 132 To indicate support for the "resumption_group" extension, the client 133 sends this extension type within the initial ClientHello message to 134 the server. 136 Upon receiving the server's response, the client checks whether the 137 "resumption_group" extension is present in the extension list of the 138 server's CertificateEntry (see Section 4.2.2 of [RFC6066]). 140 If this extension type is not included in the response of the server, 141 then the client reasons that the server is not configured to support 142 the "resumption_group" extension and proceeds with a normal 143 handshake. 145 Otherwise, the client proceeds with a normal connection establishment 146 and associates all retrieved resumption tickets to the corresponding 147 resumption group. This resumption group is formed of all SNI values 148 that are valid for the presented server certificate. 150 To establish a resumed connection to any SNI value included in a 151 resumption group, the client uses a resumption ticket associated to 152 the same group. The Client Hello of a resumed handshake MUST NOT 153 include the "resumption_group" extension. 155 Tickets received during a resumed connection MUST be associated to 156 the same resumption group of the ticket that was used during the 157 establishment of this connection. 159 If a SNI value is a member of multiple resumption groups, then the 160 client is recommended to use the freshest valid ticket for a 161 resumption handshake. It is assumed, that fresher resumption tickets 162 are more likely to be accepted by the respective server. 164 According to [RFC8446], clients MUST NOT cache tickets longer than 165 seven days. 167 Note, that TLS resumption enables a server to link resumed 168 connections to the same client. A study on the feasibility of this 169 tracking mechanism can be found in [TRAC]. To protect the client's 170 privacy against tracking via this mechanism, it is RECOMMENDED to 171 cache resumption tickets only for ten minutes. 173 4.2. Server Behavior 175 Upon receiving an initial Client Hello message, the server validates 176 if the client provided an extension of the type "resumption_group". 178 If the "resumption_group" extension is not listed by the client, then 179 the server's response MUST NOT include an entry for this extension 180 type. Otherwise, the server includes the "resumption_group" 181 extension in the extension list of the server's CertificateEntry, to 182 signal support for resumptions across SNI values. Subsequently, the 183 server proceeds with a normal handshake. 185 This extension type does not affect the server behavior for resumed 186 connection establishments. 188 5. Expectations on Certificates 190 This "resumption_group" extension forms the resumption group based on 191 the SNI values that are valid for the server's certificate. To 192 optimize the performance benefit of this extension, the server's 193 certificate is RECOMMENDED to only include SNI values that mutually 194 support the resumption of their TLS connections. Otherwise, the 195 client's resumption attempt across SNI values will fail if the server 196 does not support this practice. Note, that each failed resumption 197 handshake uses up a single-use resumption ticket. As a result, these 198 failed attempts might use up all cached single-use tickets, which 199 hinders the client to establish performance-optimized resumption 200 handshakes to legitimate SNI values. 202 6. Compatibility Issues with Middleboxes 204 [RFC8446]; Section 9.3 requires MITM proxies to remove any extensions 205 they do not understand. If a conformant MITM proxy does not support 206 this extension, it will remove this extension type from the Client 207 Hello. As a result, the server reacts as if it is not supporting 208 this extension type. 210 7. Security Considerations 212 Clients MUST only resume to a new SNI value if this SNI value is 213 valid for the server certificate presented in the original 214 connection. To facilitate a correct implementation of this 215 requirement, the resumption group is identical to the list of SNI 216 values valid for a specific server certificate. Note, that the 217 security of TLS resumptions across different SNI values is also 218 discussed in Section 4.6.1 of [RFC8446]. 220 8. IANA Considerations 222 TODO IANA needs to be requested to create an entry, resumption_group, 223 in the existing registry for ExtensionType (defined in [RFC8446]), 224 with "TLS 1.3" column values being set to "CH, EE", and "Recommended" 225 column being set to "Yes". 227 9. References 229 9.1. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, 233 DOI 10.17487/RFC2119, March 1997, 234 . 236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 238 May 2017, . 240 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 241 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 242 . 244 9.2. Informative References 246 [PERF] Sy, E., Moennich, M., Mueller, T., Federrath, H., and M. 247 Fischer, "Enhanced Performance for the encrypted Web 248 through TLS Resumption across Hostnames", 2019, 249 . 251 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 252 Extensions: Extension Definitions", RFC 6066, 253 DOI 10.17487/RFC6066, January 2011, 254 . 256 [TRAC] Sy, E., Burkert, C., Federrath, H., and M. Fischer, 257 "Tracking Users across the Web via TLS Session 258 Resumption", 2018, . 260 Acknowledgments 262 Tobias Mueller and Christian Burkert provided ideas for this 263 document. 265 Author's Address 267 Erik Sy 268 University of Hamburg 270 Email: tls@erik-sy.de