idnits 2.17.1 draft-nottingham-httpbis-alt-svc-05.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 21, 2014) is 3688 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 (-17) exists of draft-ietf-httpbis-http2-10 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Akamai 4 Intended status: Standards Track P. McManus 5 Expires: September 22, 2014 Mozilla 6 March 21, 2014 8 HTTP Alternative Services 9 draft-nottingham-httpbis-alt-svc-05 11 Abstract 13 This document specifies "alternative services" for HTTP, which allow 14 an origin's resources to be authoritatively available at a separate 15 network location, possibly accessed with a different protocol 16 configuration. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 22, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 54 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4 55 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5 56 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 5 57 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6 58 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6 59 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7 60 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 8 61 4. The Service HTTP Header Field . . . . . . . . . . . . . . . . 8 62 5. The 4NN Not Authoritative HTTP Status Code . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. The Alt-Svc Message Header Field . . . . . . . . . . . . . 9 65 6.2. The Service Message Header Field . . . . . . . . . . . . . 10 66 6.3. The 4NN Not Authoritative HTTP Status Code . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 10 69 7.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 11 70 7.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 HTTP [I-D.ietf-httpbis-p1-messaging] conflates the identification of 80 resources with their location. In other words, http:// (and 81 https://) URLs are used to both name and find things to interact 82 with. 84 In some cases, it is desirable to separate these aspects; to be able 85 to keep the same identifier for a resource, but interact with it 86 using a different location on the network. 88 For example: 90 o An origin server might wish to redirect a client to an alternative 91 when it needs to go down for maintenance, or it has found an 92 alternative in a location that is more local to the client. 93 o An origin server might wish to offer access to its resources using 94 a new protocol (such as HTTP/2 [I-D.ietf-httpbis-http2]) or one 95 using improved security (such as TLS {{RFC5246}). 96 o An origin server might wish to segment its clients into groups of 97 capabilities, such as those supporting SNI (see [RFC6066]) and 98 those not supporting it, for operational purposes. 100 This specification defines a new concept in HTTP, "Alternative 101 Services", that allows a resource to nominate additional means of 102 interacting with it on the network. It defines a general framework 103 for this in Section 2, along with a specific mechanism for 104 discovering them using HTTP headers in Section 3. 106 It also introduces a new status code in Section 5, so that origin 107 servers (or their nominated alternatives) can indicate that they are 108 not authoritative for a given origin, in cases where the wrong 109 location is used. 111 1.1. Notational Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 This document uses the Augmented BNF defined in [RFC5234] along with 118 the "OWS", "DIGIT", "parameter", "uri-host", "port" and "delta- 119 second" rules from [I-D.ietf-httpbis-p1-messaging], and uses the 120 "#rule" extension defined in Section 7 of that document. 122 2. Alternative Services Concepts 124 This specification defines a new concept in HTTP, the "alternative 125 service." When an origin (see [RFC6454]) has resources are 126 accessible through a different protocol / host / port combination, it 127 is said to have an alternative service. 129 An alternative service can be used to interact with the resources on 130 an origin server at a separate location on the network, possibly 131 using a different protocol configuration. Alternative services are 132 considered authoritative for an origin's resources, in the sense of 133 [I-D.ietf-httpbis-p1-messaging] Section 9.1. 135 For example, an origin: 137 ("http", "www.example.com", "80") 139 might declare that its resources are also accessible at the 140 alternative service: 142 ("h2", "new.example.com", "81") 144 By their nature, alternative services are explicitly at the 145 granularity of an origin; i.e., they cannot be selectively applied to 146 resources within an origin. 148 Alternative services do not replace or change the origin for any 149 given resource; in general, they are not visible to the software 150 "above" the access mechanism. The alternative service is essentially 151 alternative routing information that can also be used to reach the 152 origin in the same way that DNS CNAME or SRV records define routing 153 information at the name resolution level. Each origin maps to a set 154 of these routes - the default route is derived from origin itself and 155 the other routes are introduced based on alternative-protocol 156 information. 158 Furthermore, it is important to note that the first member of an 159 alternative service tuple is different from the "scheme" component of 160 an origin; it is more specific, identifying not only the major 161 version of the protocol being used, but potentially communication 162 options for that protocol. 164 This means that clients using an alternative service will change the 165 host, port and protocol that they are using to fetch resources, but 166 these changes MUST NOT be propagated to the application that is using 167 HTTP; from that standpoint, the URI being accessed and all 168 information derived from it (scheme, host, port) are the same as 169 before. 171 Importantly, this includes its security context; in particular, when 172 TLS [RFC5246] is in use, the alternative server will need to present 173 a certificate for the origin's host name, not that of the 174 alternative. Likewise, the Host header is still derived from the 175 origin, not the alternative service (just as it would if a CNAME were 176 being used). 178 The changes MAY, however, be made visible in debugging tools, 179 consoles, etc. 181 Formally, an alternative service is identified by the combination of: 183 o An ALPN protocol, as per [I-D.ietf-tls-applayerprotoneg] 184 o A host, as per [RFC3986] 185 o A port, as per [RFC3986] 187 Additionally, each alternative service MUST have: 189 o A freshness lifetime, expressed in seconds; see Section 2.2 191 There are many ways that a client could discover the alternative 192 service(s) associated with an origin. 194 2.1. Host Authentication 196 Clients MUST NOT use alternative services with a host other than the 197 origin's without strong server authentication; this mitigates the 198 attack described in Section 7.2. One way to achieve this is for the 199 alternative to use TLS with a certificate that is valid for that 200 origin. 202 For example, if the origin's host is "www.example.com" and an 203 alternative is offered on "other.example.com" with the "h2" protocol, 204 and the certificate offered is valid for "www.example.com", the 205 client can use the alternative. However, if "other.example.com" is 206 offered with the "h2c" protocol, the client cannot use it, because 207 there is no mechanism in that protocol to establish strong server 208 authentication. 210 Furthermore, this means that the HTTP Host header and the SNI 211 information provided in TLS by the client will be that of the origin, 212 not the alternative. 214 2.2. Alternative Service Caching 216 Mechanisms for discovering alternative services can associate a 217 freshness lifetime with them; for example, the Alt-Svc header field 218 uses the "ma" parameter. 220 Clients MAY choose to use an alternative service instead of the 221 origin at any time when it is considered fresh; see Section 2.4 for 222 specific recommendations. 224 Clients with existing connections to alternative services are not 225 required to fall back to the origin when its freshness lifetime ends; 226 i.e., the caching mechanism is intended for limiting how long an 227 alternative service can be used for establishing new requests, not 228 limiting the use of existing ones. 230 To mitigate risks associated with caching compromised values (see 231 Section 7.2 for details), user agents SHOULD examine cached 232 alternative services when they detect a change in network 233 configuration, and remove any that could be compromised (for example, 234 those whose association with the trust root is questionable). UAs 235 that do not have a means of detecting network changes SHOULD place an 236 upper bound on their lifetime. 238 2.3. Requiring Server Name Indication 240 A client must only use a TLS-based alternative service if the client 241 also supports TLS Server Name Indication (SNI) [RFC6066]. This 242 supports the conservation of IP addresses on the alternative service 243 host. 245 2.4. Using Alternative Services 247 By their nature, alternative services are optional; clients are not 248 required to use them. However, it is advantageous for clients to 249 behave in a predictable way when they are used by servers (e.g., for 250 load balancing). 252 Therefore, if a client becomes aware of an alternative service, the 253 client SHOULD use that alternative service for all requests to the 254 associated origin as soon as it is available, provided that the 255 security properties of the alternative service protocol are 256 desirable, as compared to the existing connection. 258 When a client uses an alternate service, it MUST emit the Service 259 header field Section 4 on every request using that alternate service. 261 The client is not required to block requests; the origin's connection 262 can be used until the alternative connection is established. 263 However, if the security properties of the existing connection are 264 weak (e.g. cleartext HTTP/1.1) then it might make sense to block 265 until the new connection is fully available in order to avoid 266 information leakage. 268 Furthermore, if the connection to the alternative service fails or is 269 unresponsive, the client MAY fall back to using the origin. Note, 270 however, that this could be the basis of a downgrade attack, thus 271 losing any enhanced security properties of the alternative service. 273 3. The Alt-Svc HTTP Header Field 275 A HTTP(S) origin server can advertise the availability of alternative 276 services (see Section 2) to clients by adding an Alt-Svc header field 277 to responses. 279 Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) ) 280 alternative = <"> protocol-id <"> "=" port 281 protocol-id = 283 For example: 285 Alt-Svc: "http2"=8000 287 This indicates that the "http2" protocol on the same host using the 288 indicated port (in this case, 8000). 290 Alt-Svc MAY occur in any HTTP response message, regardless of the 291 status code. 293 Alt-Svc does not allow advertisement of alternative services on other 294 hosts, to protect against various header-based attacks. 296 It can, however, have multiple values: 298 Alt-Svc: "h2c"=8000, "h2"=443 300 The value(s) advertised by Alt-Svc can be used by clients to open a 301 new connection to one or more alternative services immediately, or 302 simultaneously with subsequent requests on the same connection. 304 Intermediaries MUST NOT change or append Alt-Svc values. 306 Finally, note that while it may be technically possible to put 307 content other than printable ASCII in a HTTP header, some 308 implementations only support ASCII (or a superset of it) in header 309 field values. Therefore, this field SHOULD NOT be used to convey 310 protocol identifiers that are not printable ASCII, or those that 311 contain quote characters. 313 3.1. Caching Alt-Svc Header Field Values 315 When an alternative service is advertised using Alt-Svc, it is 316 considered fresh for 24 hours from generation of the message. This 317 can be modified with the 'ma' (max-age) parameter; 319 Alt-Svc: "h2"=443;ma=3600 321 which indicates the number of seconds since the response was 322 generated the alternative service is considered fresh for. 324 ma = delta-seconds 326 See [I-D.ietf-httpbis-p6-cache] Section 4.2.3 for details of 327 determining response age. For example, a response: 329 HTTP/1.1 200 OK 330 Content-Type: text/html 331 Cache-Control: 600 332 Age: 30 333 Alt-Svc: "h2c"=8000; ma=60 335 indicates that an alternative service is available and usable for the 336 next 60 seconds. However, the response has already been cached for 337 30 seconds (as per the Age header field value), so therefore the 338 alternative service is only fresh for the 30 seconds from when this 339 response was received, minus estimated transit time. 341 When an Alt-Svc response header is received from an origin, its value 342 invalidates and replaces all cached alternative services for that 343 origin. 345 See Section 2.2 for general requirements on caching alternative 346 services. 348 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 349 does not affect caching of Alt-Svc values. 351 4. The Service HTTP Header Field 353 The Service HTTP header field is used in requests to indicate the 354 identity of the alternate service in use, just as the Host header 355 identifies the host and port of the origin. 357 Service = uri-host [ ":" port ] 359 Service is intended to allow alternate services to detect loops, 360 differentiate traffic for purposes of load balancing, and generally 361 to ensure that it is possible to identify the intended destination of 362 traffic, since introducing this information after a protocol is in 363 use has proven to be problematic. 365 When using an Alternate Service, clients MUST include a Service 366 header in all requests. For example: 368 GET /thing 369 Host: origin.example.com 370 Service: alternate.example.net 371 User-Agent: Example/1.0 373 5. The 4NN Not Authoritative HTTP Status Code 375 The 4NN (Not Authoritative) status code indicates that the current 376 origin server (usually, but not always an alternative service; see 377 Section 2) is not authoritative for the requested resource, in the 378 sense of [I-D.ietf-httpbis-p1-messaging], Section 9.1. 380 Clients receiving 4NN (Not Authoritative) from an alternative service 381 MUST remove the corresponding entry from its alternative service 382 cache (see Section 2.2) for that origin. Regardless of the 383 idempotency of the request method, they MAY retry the request, either 384 at another alternative server, or at the origin. 386 4NN (Not Authoritative) MAY carry an Alt-Svc header field. 388 This status code MUST NOT be generated by proxies. 390 A 4NN response is cacheable by default; i.e., unless otherwise 391 indicated by the method definition or explicit cache controls (see 392 Section 4.2.2 of [I-D.ietf-httpbis-p6-cache]). 394 6. IANA Considerations 396 6.1. The Alt-Svc Message Header Field 398 This document registers Alt-Svc in the Permanent Message Header 399 Registry [RFC3864]. 401 o Header Field Name: Alt-Svc 402 o Application Protocol: http 403 o Status: standard 404 o Author/Change Controller: IETF 405 o Specification Document: [this document] 406 o Related Information: 408 6.2. The Service Message Header Field 410 This document registers Alt-Svc in the Permanent Message Header 411 Registry [RFC3864]. 413 o Header Field Name: Service 414 o Application Protocol: http 415 o Status: standard 416 o Author/Change Controller: IETF 417 o Specification Document: [this document] 418 o Related Information: 420 6.3. The 4NN Not Authoritative HTTP Status Code 422 This document registers the 4NN (Not Authoritative) HTTP Status code 423 [I-D.ietf-httpbis-p2-semantics]. 425 o Status Code: 4NN 426 o Short Description: Not Authoritative 427 o Specification: [this document], Section 5 429 7. Security Considerations 431 Identified security considerations should be enumerated in the 432 appropriate documents depending on which proposals are accepted. 433 Those listed below are generic to all uses of alternative services; 434 more specific ones might be necessary. 436 7.1. Changing Ports 438 Using an alternative service implies accessing an origin's resources 439 on an alternative port, at a minimum. An attacker that can inject 440 alternative services and listen at the advertised port is therefore 441 able to hijack an origin. 443 For example, an attacker that can add HTTP response header fields can 444 redirect traffic to a different port on the same host using the Alt- 445 Svc header field; if that port is under the attacker's control, they 446 can thus masquerade as the HTTP server. 448 This risk can be mitigated by restricting the ability to advertise 449 alternative services, and restricting who can open a port for 450 listening on that host. 452 7.2. Changing Hosts 454 When the host is changed due to the use of an alternative service, it 455 presents an opportunity for attackers to hijack communication to an 456 origin. 458 For example, if an attacker can convince a user agent to send all 459 traffic for "innocent.example.org" to "evil.example.com" by 460 successfully associating it as an alternative service, they can 461 masquerade as that origin. This can be done locally (see mitigations 462 above) or remotely (e.g., by an intermediary as a man-in-the-middle 463 attack). 465 This is the reason for the requirement in Section 2.1 that any 466 alternative service with a host different to the origin's be strongly 467 authenticated with the origin's identity; i.e., presenting a 468 certificate for the origin proves that the alternative service is 469 authorized to serve traffic for the origin. 471 However, this authorization is only as strong as the method used to 472 authenticate the alternative service. In particular, there are well- 473 known exploits to make an attacker's certificate appear as 474 legitimate. 476 Alternative services could be used to persist such an attack; for 477 example, an intermediary could man-in-the-middle TLS-protected 478 communication to a target, and then direct all traffic to an 479 alternative service with a large freshness lifetime, so that the user 480 agent still directs traffic to the attacker even when not using the 481 intermediary. 483 As a result, there is a requirement in Section 2.2 to examine cached 484 alternative services when a network change is detected. 486 7.3. Changing Protocols 488 When the ALPN protocol is changed due to the use of an alternative 489 service, the security properties of the new connection to the origin 490 can be different from that of the "normal" connection to the origin, 491 because the protocol identifier itself implies this. 493 For example, if a "https://" URI had a protocol advertised that does 494 not use some form of end-to-end encryption (most likely, TLS), it 495 violates the expectations for security that the URI scheme implies. 497 Therefore, clients cannot blindly use alternative services, but 498 instead evaluate the option(s) presented to assure that security 499 requirements and expectations (of specifications, implementations and 500 end users) are met. 502 8. References 504 8.1. Normative References 506 [I-D.ietf-httpbis-p1-messaging] 507 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 508 (HTTP/1.1): Message Syntax and Routing", 509 draft-ietf-httpbis-p1-messaging-26 (work in progress), 510 February 2014. 512 [I-D.ietf-httpbis-p6-cache] 513 Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 514 Transfer Protocol (HTTP/1.1): Caching", 515 draft-ietf-httpbis-p6-cache-26 (work in progress), 516 February 2014. 518 [I-D.ietf-tls-applayerprotoneg] 519 Friedl, S., Popov, A., Langley, A., and S. Emile, 520 "Transport Layer Security (TLS) Application Layer Protocol 521 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 522 (work in progress), March 2014. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 528 Resource Identifier (URI): Generic Syntax", STD 66, 529 RFC 3986, January 2005. 531 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 532 Specifications: ABNF", STD 68, RFC 5234, January 2008. 534 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 535 Extension Definitions", RFC 6066, January 2011. 537 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 538 December 2011. 540 8.2. Informative References 542 [I-D.ietf-httpbis-http2] 543 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 544 Protocol version 2", draft-ietf-httpbis-http2-10 (work in 545 progress), February 2014. 547 [I-D.ietf-httpbis-p2-semantics] 548 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 549 (HTTP/1.1): Semantics and Content", 550 draft-ietf-httpbis-p2-semantics-26 (work in progress), 551 February 2014. 553 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 554 Procedures for Message Header Fields", BCP 90, RFC 3864, 555 September 2004. 557 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 558 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 560 Appendix A. Acknowledgements 562 Thanks to Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, 563 Erik Nygren, Paul Hoffman, Adam Langley, Will Chan and Richard Barnes 564 for their feedback and suggestions. 566 The Alt-Svc header field was influenced by the design of the 567 Alternative-Protocol header in SPDY. 569 Authors' Addresses 571 Mark Nottingham 572 Akamai 574 Email: mnot@mnot.net 575 URI: http://www.mnot.net/ 577 Patrick McManus 578 Mozilla 580 Email: mcmanus@ducksong.com 581 URI: https://mozillians.org/u/pmcmanus/