idnits 2.17.1 draft-bishop-httpbis-sni-altsvc-02.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 (May 24, 2018) is 2156 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) -- Looks like a reference, but probably isn't: '1' on line 405 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-08 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track May 24, 2018 5 Expires: November 25, 2018 7 The "SNI" Alt-Svc Parameter 8 draft-bishop-httpbis-sni-altsvc-02 10 Abstract 12 HTTP Alternative Services provides a mechanism for an origin to 13 declare that its content is accessible via some other combination of 14 host, port, and protocol. In the process of using such an 15 alternative, an observer can identify that the client is requesting 16 resources from a particular hostname. 18 This document extends HTTP Alternative Services, in combination with 19 Secondary Certificate Authentication, to enable clients not to 20 disclose the origin to which they intend to connect. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 25, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 59 2. The "sni" Alt-Svc Extension . . . . . . . . . . . . . . . . . 3 60 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. SNI of Colocated Domain . . . . . . . . . . . . . . . . . 4 62 3.2. Wildcard Subdomains . . . . . . . . . . . . . . . . . . . 5 63 3.3. Omitting SNI . . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. SNI of Unrelated Domain . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . 9 70 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Confidentiality and authentication during communication are primary 77 goals of using TLS to secure traffic on the Internet. However, due 78 to the nature of TLS, certain information is inherently not 79 confidential - notably, the hostname and the corresponding 80 certificate of the origin to which the client is connecting are 81 transferred unencrypted in the Server Name Indication extension [SNI] 82 and the server's Certificate message [TLS12]. 84 While the client identity can be obscured by using TLS renegotiation 85 immediately after the handshake (in TLS 1.2) or by using TLS 1.3 86 [TLS13], the server is not afforded such privacy considerations. 88 Servers may also have wildcard certificates which do not enumerate 89 specific subdomains, but clients will disclose the first subdomain 90 used on a connection via the SNI extension when establishing the 91 connection. 93 [SNIEncryption] discusses a potential solution to these issues in 94 Section 3, HTTP Co-Tenancy Fronting, but notes both discoverability 95 and server authentication issues with that approach. This document 96 provides a mechanism to address both limitations. 98 1.1. Usage 100 In [AltSvc], once a client has received a validated Alternative 101 Service record for an origin, it "SHOULD use that alternative service 102 for all requests to the associated origin as soon as it is available, 103 provided the alternative service information is fresh (Section 2.2) 104 and the security properties of the alternative service protocol are 105 desirable, as compared to the existing connection." However, the 106 client "MUST have reasonable assurances that the alternative service 107 is under control of and valid for the whole origin ... established 108 through use of a TLS-based protocol with the certificate checks 109 defined in [RFC2818]." This causes the origin to be disclosed in the 110 SNI extension while connecting to the alternative, and the origin's 111 certificate to be returned by the alternative, creating the same 112 privacy issues as connecting directly to the origin. 114 The extension described in Section 2 enables an origin to declare 115 that reasonable assurances should be obtained, not by requesting the 116 desired hostname in the TLS handshake, but by requesting it via 117 [SecondaryCerts]. The validation checks from [RFC2818] are applied 118 to this certificate. 120 Because the entire exchange happens inside TLS, a passive observer 121 cannot identify the hostname(s) the client might be requesting. 123 1.2. Notational Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", 132 "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", 133 "COULD", "POSSIBLE", and "MIGHT" in this document are to be 134 interpreted as described in [RFC6919]. 136 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 137 defined in [RFC5234]. 139 2. The "sni" Alt-Svc Extension 141 When an origin wishes to nominate a "fronting server", it includes 142 the "sni" parameter in its alternative service entry. 144 Syntax: 146 sni = ( reg-name / empty-string ) 147 empty-string = DQUOTE DQUOTE 149 "reg-name" is defined in Section 3.2.2 of [RFC3986]. 151 When processing such an alternative, clients SHOULD present the 152 hostname given in the "sni" parameter in the SNI extension during the 153 TLS handshake. If the hostname given is an empty string, clients 154 SHOULD omit the SNI extension from the TLS handshake. The server 155 MUST return a valid certificate which covers at least one of the 156 following: 158 o The hostname indicated in the SNI extension 160 o The hostname of the origin that published the alternative 162 o The hostname used for connecting to the alternative 164 The client MUST validate the certificate in the handshake for 165 authenticity according to [RFC2818] and ensure that it is valid for 166 at least one of these names. Clients SHOULD NOT accept certificates 167 issued to the IP address of the alternative unless the alternative is 168 specified as an IP literal. 170 If the certificate is not valid for the origin's hostname, the client 171 MUST NOT make requests to any origin corresponding to this 172 certificate. In this case, the client SHOULD send a 173 "CERTIFICATE_REQUEST" frame including an SNI extension indicating the 174 origin which published the alternative service immediately upon 175 connecting. If no corresponding "CERTIFICATE" frame is presented by 176 the server after a reasonable timeout, or if the server's SETTINGS 177 frame does not include the "SETTINGS_HTTP_CERT_AUTH" setting, the 178 client MUST consider the alternative connection to have failed. 180 3. Examples 182 3.1. SNI of Colocated Domain 184 Suppose a client has received the following Alt-Svc entry for 185 sensitive.example.com in the past: 187 h2="innocence.org:443";ma=2635200;persist=true;sni=innocence.org 189 If the client now wishes to make a request to 190 https://sensitive.example.com/private, it would perform a DNS 191 resolution for innocence.org. The client would then open a TCP 192 connection to the resulting IP address and begin a TLS handshake. 194 In the client's TLS handshake, it would request a certificate for the 195 hostname "innocence.org". The TLS server would present such a 196 certificate, issued by an authority trusted by the client. The 197 client will validate the certificate for the name 198 "sensitive.example.com". When validation fails, the client will try 199 to validate the certificate for the name "innocence.org", which will 200 succeed. After validation succeeds, the client will send a 201 "CERTIFICATE_REQUEST" frame asking that the server also authenticate 202 with a certificate for sensitive.example.com. 204 After receiving the "CERTIFICATE" frame proving possession of a 205 certificate for sensitive.example.com, the client will verify that 206 this certificate is trusted. If so, the client will proceed to send 207 HTTP/2 requests to the server requesting the resource 208 https://sensitive.example.com/private. 210 3.2. Wildcard Subdomains 212 Suppose a client has received the following Alt-Svc entry for 213 sensitive.example.com in the past: 215 h2="www.example.com:443";ma=2635200;persist=true;sni=www.example.com 217 If the client now wishes to make a request to 218 https://sensitive.example.com/private, it would perform a DNS 219 resolution for www.example.com, the specified alternative. The 220 client would then open a TCP connection to the resulting IP address 221 and begin a TLS handshake. 223 In the client's TLS handshake, it would request a certificate for the 224 hostname www.example.com. The TLS server would present a certificate 225 which included www.example.com as one of the covered hostnames. 227 Suppose that the certificate with which the server authenticated also 228 contained a Subject Alternative Name of "*.example.com". Because the 229 certificate covers the desired origin, the client would perform 230 validity checks on this certificate. 232 If the certificate is trusted, the client will proceed to send HTTP/2 233 requests to the server requesting the resource 234 https://sensitive.example.com/private. 236 3.3. Omitting SNI 238 Suppose a client has received the following Alt-Svc entry for 239 sensitive.example.com in the past: 241 h2="alternative.example.com:443";ma=2635200;persist=true;sni="" 242 If the client now wishes to make a request to 243 https://sensitive.example.com/private, it would perform a DNS 244 resolution for alternative.example.com, the specified alternative. 245 The client would then open a TCP connection to the resulting IP 246 address and begin a TLS handshake. 248 In the client's TLS handshake, it would omit the Server Name 249 Indication extension. The TLS server would present a certificate 250 according to its configured defaults. 252 The server would supply a certificate that covers 253 sensitive.example.com, for example because it contains a Subject 254 Alternative Name of "*.example.com", and the client would perform 255 validity checks on this certificate. 257 If the supplied certificate does not cover sensitive.example.com, or 258 is not valid, the client will terminate the connection. 260 3.4. SNI of Unrelated Domain 262 Suppose a client has received the following Alt-Svc entry for 263 sensitive.example.com in the past: 265 h2=":443";ma=2635200;persist=true;sni=other.example 267 If the client now wishes to make a request to 268 https://sensitive.example.com/private, it would perform a DNS 269 resolution for sensitive.example.com (the Alt-Svc entry does not 270 specify a different hostname). The client would then open a TCP 271 connection to the resulting IP address and begin a TLS handshake. 273 In the client's TLS handshake, it would request a certificate for the 274 hostname "other.example". The TLS server does not a have a 275 certificate for this hostname, but it would return a certificate for 276 sensitive.example.com, issued by an authority trusted by the client, 277 and the client will successfully validate the certificate for the 278 name "sensitive.example.com". 280 Note that an active attacker could identify this server by sending a 281 Client Hello with the same SNI value and observing the certificate 282 the server uses to authenticate. The server could mitigate this by 283 authenticating with a certificate for other.example. 285 4. Security Considerations 287 [AltSvc] permits clients to ignore unrecognized parameters. As a 288 result, servers publishing records with the "sni" parameter cannot be 289 assured that clients will not include their origin in the SNI header 290 when connecting to the nominated alternative. If, for security 291 reasons, an origin wishes its identity never to be disclosed when the 292 alternative is being used, an alternative mechanism would be required 293 to ascertain client support before generating the Alt-Svc record. 295 Clients will need to connect directly to the origin at least once in 296 order to receive the Alt-Svc entry via an HTTP header or "ALTSVC" 297 frame, thus disclosing their use of the origin to the network on the 298 first connection. This could be mitigated by future work defining a 299 way to publish alternative services in a mechanism which can be 300 retrieved confidentially, such as via DNS in combination with 301 [RFC7858] or [DoH]. 303 However, servers which publish Alt-Svc records over unencrypted 304 channels (HTTP connections without TLS) or channels without client 305 authorization (DNS, or publicly accessible HTTP resources) enable 306 active observers to build a map of fronting servers by collecting 307 Alt-Svc advertisements. Servers SHOULD CONSIDER this trade-off in 308 deciding when and how to make Alt-Svc records available to 309 unauthenticated parties. 311 While concealing information from passive observers is beneficial, 312 low-effort active attacks still exist. If an attacker can collect 313 the actual server identity by sending a Client Hello with the same 314 SNI value, the usefulness of this technique is limited. Server 315 deployments SHOULD reserve sensitive domains for use with Secondary 316 Certificates or conceal them inside wildcards in order to mitigate 317 this. 319 5. IANA Considerations 321 The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" 322 defines the name space for parameters, as described in [AltSvc]. It 323 is maintained at http://www.iana.org/assignments/http-alt-svc- 324 parameters [1]. 326 This document registers the following parameter: 328 Name: "sni" 330 Specification: This document 332 6. References 333 6.1. Normative References 335 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 336 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 337 April 2016, . 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 345 DOI 10.17487/RFC2818, May 2000, 346 . 348 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 349 Resource Identifier (URI): Generic Syntax", STD 66, 350 RFC 3986, DOI 10.17487/RFC3986, January 2005, 351 . 353 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 354 Specifications: ABNF", STD 68, RFC 5234, 355 DOI 10.17487/RFC5234, January 2008, 356 . 358 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 359 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 360 DOI 10.17487/RFC6919, April 2013, 361 . 363 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 364 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 365 May 2017, . 367 [SecondaryCerts] 368 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 369 Certificate Authentication in HTTP/2", draft-bishop- 370 httpbis-http2-additional-certs-05 (work in progress), 371 October 2017. 373 [SNI] Eastlake 3rd, D., "Transport Layer Security (TLS) 374 Extensions: Extension Definitions", RFC 6066, 375 DOI 10.17487/RFC6066, January 2011, 376 . 378 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 379 (TLS) Protocol Version 1.2", RFC 5246, 380 DOI 10.17487/RFC5246, August 2008, 381 . 383 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 384 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 385 March 2018. 387 6.2. Informative References 389 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 390 (DOH)", draft-ietf-doh-dns-over-https-08 (work in 391 progress), May 2018. 393 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 394 and P. Hoffman, "Specification for DNS over Transport 395 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 396 2016, . 398 [SNIEncryption] 399 Huitema, C. and E. Rescorla, "Issues and Requirements for 400 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 401 (work in progress), May 2018. 403 6.3. URIs 405 [1] http://www.iana.org/assignments/http-alt-svc-parameters 407 Appendix A. Acknowledgements 409 Conversations with Benjamin Schwartz helped to flesh out this idea. 411 Author's Address 413 Mike Bishop 414 Akamai 416 Email: mbishop@evequefou.be