idnits 2.17.1 draft-ietf-httpbis-alt-svc-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 (July 4, 2014) is 3583 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-13 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Nottingham 3 Internet-Draft Akamai 4 Intended status: Standards Track P. McManus 5 Expires: January 5, 2015 Mozilla 6 J. Reschke 7 greenbytes 8 July 4, 2014 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-02 13 Abstract 15 This document specifies "alternative services" for HTTP, which allow 16 an origin's resources to be authoritatively available at a separate 17 network location, possibly accessed with a different protocol 18 configuration. 20 Editorial Note (To be removed by RFC Editor) 22 Discussion of this draft takes place on the HTTPBIS working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 . 26 Working Group information can be found at 27 and ; 28 source code and issues list for tis draft can be found at 29 . 31 The changes in this draft are summarized in Appendix A. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 69 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4 70 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5 71 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 6 72 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6 73 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6 74 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7 75 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 9 76 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 10 77 5. The Alt-Svc-Used HTTP Header Field . . . . . . . . . . . . . . 11 78 6. The 421 Not Authoritative HTTP Status Code . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 12 81 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 13 82 8. Internationalization Considerations . . . . . . . . . . . . . 13 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 13 85 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 13 86 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 14 87 9.4. Tracking Clients Using Alternative Services . . . . . . . 14 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 Appendix A. Change Log (to be removed by RFC Editor before 93 publication) . . . . . . . . . . . . . . . . . . . . 16 94 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 16 95 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 16 96 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 16 98 1. Introduction 100 HTTP [RFC7230] conflates the identification of resources with their 101 location. In other words, "http://" (and "https://") URLs are used 102 to both name and find things to interact with. 104 In some cases, it is desirable to separate these aspects; to be able 105 to keep the same identifier for a resource, but interact with it 106 using a different location on the network. 108 For example: 110 o An origin server might wish to redirect a client to an alternative 111 when it needs to go down for maintenance, or it has found an 112 alternative in a location that is more local to the client. 114 o An origin server might wish to offer access to its resources using 115 a new protocol (such as HTTP/2, see [HTTP2]) or one using improved 116 security (such as Transport Layer Security (TLS), see [RFC5246]). 118 o An origin server might wish to segment its clients into groups of 119 capabilities, such as those supporting Server Name Indication 120 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for 121 operational purposes. 123 This specification defines a new concept in HTTP, "Alternative 124 Services", that allows a resource to nominate additional means of 125 interacting with it on the network. It defines a general framework 126 for this in Section 2, along with specific mechanisms for advertising 127 their existence using HTTP header fields (Section 3) or an HTTP/2 128 frame type (Section 4). 130 It also introduces a new status code in Section 6, so that origin 131 servers (or their nominated alternatives) can indicate that they are 132 not authoritative for a given origin, in cases where the wrong 133 location is used. 135 1.1. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 This document uses the Augmented BNF defined in [RFC5234] along with 142 the "OWS", "delta-seconds", "parameter", "port", "quoted-string", 143 "token", and "uri-host" rules from [RFC7230], and uses the "#rule" 144 extension defined in Section 7 of that document. 146 2. Alternative Services Concepts 148 This specification defines a new concept in HTTP, the "alternative 149 service". When an origin (see [RFC6454]) has resources that are 150 accessible through a different protocol / host / port combination, it 151 is said to have an alternative service. 153 An alternative service can be used to interact with the resources on 154 an origin server at a separate location on the network, possibly 155 using a different protocol configuration. Alternative services are 156 considered authoritative for an origin's resources, in the sense of 157 [RFC7230], Section 9.1. 159 For example, an origin: 161 ("http", "www.example.com", "80") 163 might declare that its resources are also accessible at the 164 alternative service: 166 ("h2", "new.example.com", "81") 168 By their nature, alternative services are explicitly at the 169 granularity of an origin; i.e., they cannot be selectively applied to 170 resources within an origin. 172 Alternative services do not replace or change the origin for any 173 given resource; in general, they are not visible to the software 174 "above" the access mechanism. The alternative service is essentially 175 alternative routing information that can also be used to reach the 176 origin in the same way that DNS CNAME or SRV records define routing 177 information at the name resolution level. Each origin maps to a set 178 of these routes -- the default route is derived from origin itself 179 and the other routes are introduced based on alternative-protocol 180 information. 182 Furthermore, it is important to note that the first member of an 183 alternative service tuple is different from the "scheme" component of 184 an origin; it is more specific, identifying not only the major 185 version of the protocol being used, but potentially communication 186 options for that protocol. 188 This means that clients using an alternative service will change the 189 host, port and protocol that they are using to fetch resources, but 190 these changes MUST NOT be propagated to the application that is using 191 HTTP; from that standpoint, the URI being accessed and all 192 information derived from it (scheme, host, port) are the same as 193 before. 195 Importantly, this includes its security context; in particular, when 196 TLS [RFC5246] is in use, the alternative server will need to present 197 a certificate for the origin's host name, not that of the 198 alternative. Likewise, the Host header field ([RFC7230], Section 199 5.4) is still derived from the origin, not the alternative service 200 (just as it would if a CNAME were being used). 202 The changes MAY, however, be made visible in debugging tools, 203 consoles, etc. 205 Formally, an alternative service is identified by the combination of: 207 o An Application Layer Protocol Negotiation (ALPN) protocol, as per 208 [ALPN] 210 o A host, as per [RFC3986], Section 3.2.2 212 o A port, as per [RFC3986], Section 3.2.3 214 Additionally, each alternative service MUST have: 216 o A freshness lifetime, expressed in seconds; see Section 2.2 218 There are many ways that a client could discover the alternative 219 service(s) associated with an origin. This document describes two 220 such mechanisms: an HTTP header field (Section 3) and an HTTP/2 frame 221 type (Section 4). 223 2.1. Host Authentication 225 Clients MUST NOT use alternative services with a host other than the 226 origin's without strong server authentication; this mitigates the 227 attack described in Section 9.2. One way to achieve this is for the 228 alternative to use TLS with a certificate that is valid for that 229 origin. 231 For example, if the origin's host is "www.example.com" and an 232 alternative is offered on "other.example.com" with the "h2" protocol, 233 and the certificate offered is valid for "www.example.com", the 234 client can use the alternative. However, if "other.example.com" is 235 offered with the "h2c" protocol, the client cannot use it, because 236 there is no mechanism in that protocol to establish strong server 237 authentication. 239 Furthermore, this means that the HTTP Host header field and the SNI 240 information provided in TLS by the client will be that of the origin, 241 not the alternative. 243 2.2. Alternative Service Caching 245 Mechanisms for discovering alternative services can associate a 246 freshness lifetime with them; for example, the Alt-Svc header field 247 uses the "ma" parameter. 249 Clients MAY choose to use an alternative service instead of the 250 origin at any time when it is considered fresh; see Section 2.4 for 251 specific recommendations. 253 Clients with existing connections to alternative services are not 254 needed to fall back to the origin when its freshness lifetime ends; 255 i.e., the caching mechanism is intended for limiting how long an 256 alternative service can be used for establishing new requests, not 257 limiting the use of existing ones. 259 To mitigate risks associated with caching compromised values (see 260 Section 9.2 for details), user agents SHOULD examine cached 261 alternative services when they detect a change in network 262 configuration, and remove any that could be compromised (for example, 263 those whose association with the trust root is questionable). UAs 264 that do not have a means of detecting network changes SHOULD place an 265 upper bound on their lifetime. 267 2.3. Requiring Server Name Indication 269 A client MUST only use a TLS-based alternative service if the client 270 also supports TLS Server Name Indication (SNI). This supports the 271 conservation of IP addresses on the alternative service host. 273 2.4. Using Alternative Services 275 By their nature, alternative services are OPTIONAL: clients do not 276 need to use them. However, it is advantageous for clients to behave 277 in a predictable way when they are used by servers (e.g., for load 278 balancing). 280 Therefore, if a client becomes aware of an alternative service, the 281 client SHOULD use that alternative service for all requests to the 282 associated origin as soon as it is available, provided that the 283 security properties of the alternative service protocol are 284 desirable, as compared to the existing connection. 286 When a client uses an alternate service, it MUST emit the Alt-Svc- 287 Used header field (Section 5) on every request using that alternate 288 service. 290 The client does not need to block requests; the origin's connection 291 can be used until the alternative connection is established. 292 However, if the security properties of the existing connection are 293 weak (e.g. cleartext HTTP/1.1) then it might make sense to block 294 until the new connection is fully available in order to avoid 295 information leakage. 297 Furthermore, if the connection to the alternative service fails or is 298 unresponsive, the client MAY fall back to using the origin. Note, 299 however, that this could be the basis of a downgrade attack, thus 300 losing any enhanced security properties of the alternative service. 302 3. The Alt-Svc HTTP Header Field 304 An HTTP(S) origin server can advertise the availability of 305 alternative services to clients by adding an Alt-Svc header field to 306 responses. 308 Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) ) 309 alternative = protocol-id "=" alt-authority 310 protocol-id = token ; percent-encoded ALPN protocol identifier 311 alt-authority = token / quoted-string 312 ; containing [ uri-host ] ":" port 314 ALPN protocol names are octet sequences with no additional 315 constraints on format. Octets not allowed in tokens ([RFC7230], 316 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 317 [RFC3986]. Consequently, the octet representing the percent 318 character "%" (hex 25) MUST be percent-encoded as well. 320 In order to have precisely one way to represent any ALPN protocol 321 name, the following additional constraints apply: 323 1. Octets in the ALPN protocol MUST NOT be percent-encoded if they 324 are valid token characters except "%", and 326 2. When using percent-encoding, uppercase hex digits MUST be used. 328 With these constraints, recipients can apply simple string comparison 329 to match protocol identifiers. 331 The "alt-authority" component consists of an OPTIONAL uri-host 332 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 333 number. 335 For example: 337 Alt-Svc: http2=":8000" 339 This indicates the "http2" protocol on the same host using the 340 indicated port 8000. 342 An example involving a change of host: 344 Alt-Svc: http2="new.example.org:80" 346 This indicates the "http2" protocol on the host "new.example.org", 347 running on port 80. Note that the "quoted-string" syntax needs to be 348 used when a host is specified in addition to a port (":" is not an 349 allowed character in "token"). 351 Examples for protocol name escaping: 353 +--------------------+-------------+---------------------+ 354 | ALPN protocol name | protocol-id | Note | 355 +--------------------+-------------+---------------------+ 356 | http2 | http2 | No escaping needed | 357 +--------------------+-------------+---------------------+ 358 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 359 +--------------------+-------------+---------------------+ 360 | x%y | x%25y | "%" needs escaping | 361 +--------------------+-------------+---------------------+ 363 Alt-Svc MAY occur in any HTTP response message, regardless of the 364 status code. 366 Alt-Svc does not allow advertisement of alternative services on other 367 hosts, to protect against various header-based attacks. 369 It can, however, have multiple values: 371 Alt-Svc: h2c=":8000", h2=":443" 373 The value(s) advertised by Alt-Svc can be used by clients to open a 374 new connection to one or more alternative services immediately, or 375 simultaneously with subsequent requests on the same connection. 377 To reduce the ability of servers to track individual clients over 378 time (see Section 9.4), an alternative service indication sent by a 379 client SHOULD NOT include any alternative service information other 380 than the protocol, host and port. 382 When using HTTP/2 ([HTTP2]), clients SHOULD instead send an ALTSVC 383 frame. A single ALTSVC frame can be sent for a connection; a new 384 frame is not needed for every request. 386 Note that all field elements that allow "quoted-string" syntax MUST 387 be processed as per Section 3.2.6 of [RFC7230]. 389 3.1. Caching Alt-Svc Header Field Values 391 When an alternative service is advertised using Alt-Svc, it is 392 considered fresh for 24 hours from generation of the message. This 393 can be modified with the 'ma' (max-age) parameter; 395 Alt-Svc: h2=":443"; ma=3600 397 which indicates the number of seconds since the response was 398 generated the alternative service is considered fresh for. 400 ma = delta-seconds 402 See Section 4.2.3 of [RFC7234] for details of determining response 403 age. 405 For example, a response: 407 HTTP/1.1 200 OK 408 Content-Type: text/html 409 Cache-Control: 600 410 Age: 30 411 Alt-Svc: h2c=":8000"; ma=60 413 indicates that an alternative service is available and usable for the 414 next 60 seconds. However, the response has already been cached for 415 30 seconds (as per the Age header field value), so therefore the 416 alternative service is only fresh for the 30 seconds from when this 417 response was received, minus estimated transit time. 419 When an Alt-Svc response header field is received from an origin, its 420 value invalidates and replaces all cached alternative services for 421 that origin. 423 See Section 2.2 for general requirements on caching alternative 424 services. 426 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 427 does not affect caching of Alt-Svc values. 429 4. The ALTSVC HTTP/2 Frame 431 The ALTSVC HTTP/2 frame ([HTTP2], Section 4) advertises the 432 availability of an alternative service to an HTTP/2 client. 434 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 435 that do not support this frame can safely ignore it. 437 An ALTSVC frame on a client-initiated stream indicates that the 438 conveyed alternative service is associated with the origin of that 439 stream. 441 An ALTSVC frame on stream 0 indicates that the conveyed alternative 442 service is associated with the origin contained in the Origin field 443 of the frame. An association with an origin that the client does not 444 consider authoritative for the current connection MUST be ignored. 446 The ALTSVC frame type is 0xa (decimal 10). 448 0 1 2 3 449 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Max-Age (32) | 452 +-------------------------------+---------------+---------------+ 453 | Port (16) | Proto-Len (8) | 454 +-------------------------------+---------------+---------------+ 455 | Protocol-ID (*) | 456 +---------------+-----------------------------------------------+ 457 | Host-Len (8) | Host (*) ... 458 +---------------+-----------------------------------------------+ 459 | Origin? (*) ... 460 +---------------------------------------------------------------+ 462 ALTSVC Frame Payload 464 The ALTSVC frame contains the following fields: 466 Max-Age: An unsigned, 32-bit integer indicating the freshness 467 lifetime of the alternative service association, as per 468 Section 2.2. 470 Port: An unsigned, 16-bit integer indicating the port that the 471 alternative service is available upon. 473 Proto-Len: An unsigned, 8-bit integer indicating the length, in 474 octets, of the Protocol-ID field. 476 Protocol-ID: A sequence of bytes (length determined by "Proto-Len") 477 containing the ALPN protocol identifier of the alternative 478 service. 480 Host-Len: An unsigned, 8-bit integer indicating the length, in 481 octets, of the Host header field. 483 Host: A sequence of characters (length determined by "Host-Len") 484 containing an ASCII string indicating the host that the 485 alternative service is available upon. 487 Origin: An OPTIONAL sequence of characters (length determined by 488 subtracting the length of all preceding fields from the frame 489 length) containing the ASCII serialisation of an origin 490 ([RFC6454], Section 6.2) that the alternate service is applicable 491 to. 493 The ALTSVC frame does not define any flags. 495 The ALTSVC frame is intended for receipt by clients; a server that 496 receives an ALTSVC frame MUST treat it as a connection error of type 497 PROTOCOL_ERROR. 499 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 500 forward ALTSVC frames, though it can use the information contained in 501 ALTSVC frames in forming new ALTSVC frames to send to its own 502 clients. 504 5. The Alt-Svc-Used HTTP Header Field 506 The Alt-Svc-Used HTTP header field is used in requests to indicate 507 that an alternate service is in use. 509 Alt-Svc-Used = ("1" / "0") *( OWS ";" OWS Alt-Svc-Used-Ext ) 510 Alt-Svc-Used-Ext = token "=" ( token / quoted-string ) 512 Alt-Svc-Used is intended to allow alternate services to avoid sending 513 alternative service indications where there is a risk of generating a 514 loops. It also allows a service to identify requests for accounting 515 and load balancing purposes. 517 When using an alternative service, clients MUST include a Alt-Svc- 518 Used header field in all requests. 520 For example: 522 GET /thing HTTP/1.1 523 Host: origin.example.com 524 Alt-Svc-Used: 1 526 The extension parameters (Alt-Svc-Used-Ext) are reserved for future 527 use; specifications that want to define an extension will need to 528 update this document (and ought to introduce an extension registry). 530 6. The 421 Not Authoritative HTTP Status Code 532 The 421 (Not Authoritative) status code is defined in [HTTP2], 533 Section 9.1.2 to indicate that the current server instance is not 534 authoritative for the requested resource. This can be used to 535 indicate that an alternative service is not authoritative; see 536 Section 2). 538 Clients receiving 421 (Not Authoritative) from an alternative service 539 MUST remove the corresponding entry from its alternative service 540 cache (see Section 2.2) for that origin. Regardless of the 541 idempotency of the request method, they MAY retry the request, either 542 at another alternative server, or at the origin. 544 A 421 (Not Authoritative) response MAY carry an Alt-Svc header field. 546 7. IANA Considerations 548 7.1. Header Field Registrations 550 HTTP header fields are registered within the "Message Headers" 551 registry maintained at 552 . 554 This document defines the following HTTP header fields, so their 555 associated registry entries shall be added according to the permanent 556 registrations below (see [BCP90]): 558 +-------------------+----------+----------+-----------+ 559 | Header Field Name | Protocol | Status | Reference | 560 +-------------------+----------+----------+-----------+ 561 | Alt-Svc | http | standard | Section 3 | 562 | Alt-Svc-Used | http | standard | Section 5 | 563 +-------------------+----------+----------+-----------+ 565 The change controller is: "IETF (iesg@ietf.org) - Internet 566 Engineering Task Force". 568 7.2. The ALTSVC HTTP/2 Frame Type 570 This document registers the ALTSVC frame type in the HTTP/2 Frame 571 Types registry ([HTTP2], Section 11.2). 573 Frame Type: ALTSVC 575 Code: 0xa 577 Specification: Section 4 of this document 579 8. Internationalization Considerations 581 An internationalized domain name that appears in either the header 582 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 583 using A-labels ([RFC5890], Section 2.3.2.1). 585 9. Security Considerations 587 9.1. Changing Ports 589 Using an alternative service implies accessing an origin's resources 590 on an alternative port, at a minimum. An attacker that can inject 591 alternative services and listen at the advertised port is therefore 592 able to hijack an origin. 594 For example, an attacker that can add HTTP response header fields can 595 redirect traffic to a different port on the same host using the Alt- 596 Svc header field; if that port is under the attacker's control, they 597 can thus masquerade as the HTTP server. 599 This risk can be mitigated by restricting the ability to advertise 600 alternative services, and restricting who can open a port for 601 listening on that host. 603 9.2. Changing Hosts 605 When the host is changed due to the use of an alternative service, it 606 presents an opportunity for attackers to hijack communication to an 607 origin. 609 For example, if an attacker can convince a user agent to send all 610 traffic for "innocent.example.org" to "evil.example.com" by 611 successfully associating it as an alternative service, they can 612 masquerade as that origin. This can be done locally (see mitigations 613 above) or remotely (e.g., by an intermediary as a man-in-the-middle 614 attack). 616 This is the reason for the requirement in Section 2.1 that any 617 alternative service with a host different to the origin's be strongly 618 authenticated with the origin's identity; i.e., presenting a 619 certificate for the origin proves that the alternative service is 620 authorized to serve traffic for the origin. 622 However, this authorization is only as strong as the method used to 623 authenticate the alternative service. In particular, there are well- 624 known exploits to make an attacker's certificate appear as 625 legitimate. 627 Alternative services could be used to persist such an attack; for 628 example, an intermediary could man-in-the-middle TLS-protected 629 communication to a target, and then direct all traffic to an 630 alternative service with a large freshness lifetime, so that the user 631 agent still directs traffic to the attacker even when not using the 632 intermediary. 634 As a result, there is a requirement in Section 2.2 to examine cached 635 alternative services when a network change is detected. 637 9.3. Changing Protocols 639 When the ALPN protocol is changed due to the use of an alternative 640 service, the security properties of the new connection to the origin 641 can be different from that of the "normal" connection to the origin, 642 because the protocol identifier itself implies this. 644 For example, if a "https://" URI had a protocol advertised that does 645 not use some form of end-to-end encryption (most likely, TLS), it 646 violates the expectations for security that the URI scheme implies. 648 Therefore, clients cannot blindly use alternative services, but 649 instead evaluate the option(s) presented to assure that security 650 requirements and expectations (of specifications, implementations and 651 end users) are met. 653 9.4. Tracking Clients Using Alternative Services 655 The alternative service indicator (Section 5) provided by clients 656 provides a server the means of correlating requests. If the 657 alternative service indicator includes a sufficiently unique 658 identifier, requests made to an alternative service can be correlated 659 with the original alternative service advertisement. 661 Clients that do not wish to be tracked MAY choose to ignore 662 alternative service advertisements. 664 In a browser, any alternative service information MUST be removed 665 when origin-specific data is cleared (for instance, when cookies are 666 cleared). 668 10. Acknowledgements 670 Thanks to Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, 671 Erik Nygren, Paul Hoffman, Adam Langley, Will Chan and Richard Barnes 672 for their feedback and suggestions. 674 The Alt-Svc header field was influenced by the design of the 675 Alternate-Protocol header field in SPDY. 677 11. References 679 11.1. Normative References 681 [ALPN] Friedl, S., Popov, A., Langley, A., and S. Emile, 682 "Transport Layer Security (TLS) Application Layer Protocol 683 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 684 (work in progress), March 2014. 686 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 687 Transfer Protocol version 2", draft-ietf-httpbis-http2-13 688 (work in progress), June 2014. 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, March 1997. 693 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 694 Resource Identifier (URI): Generic Syntax", STD 66, 695 RFC 3986, January 2005. 697 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 698 Specifications: ABNF", STD 68, RFC 5234, January 2008. 700 [RFC5890] Klensin, J., "Internationalized Domain Names for 701 Applications (IDNA): Definitions and Document Framework", 702 RFC 5890, August 2010. 704 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 705 Extension Definitions", RFC 6066, January 2011. 707 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 708 December 2011. 710 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 711 Protocol (HTTP/1.1): Message Syntax and Routing", 712 RFC 7230, June 2014. 714 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 715 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 716 RFC 7234, June 2014. 718 11.2. Informative References 720 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 721 Procedures for Message Header Fields", BCP 90, RFC 3864, 722 September 2004. 724 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 725 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 727 Appendix A. Change Log (to be removed by RFC Editor before publication) 729 A.1. Since draft-nottingham-httpbis-alt-svc-05 731 This is the first version after adoption of 732 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 733 only contains editorial changes. 735 A.2. Since draft-ietf-httpbis-alt-svc-00 737 Selected 421 as proposed status code for "Not Authoritative". 739 Changed header field syntax to use percent-encoding of ALPN protocol 740 names (). 742 A.3. Since draft-ietf-httpbis-alt-svc-01 744 Updated HTTP/1.1 references. 746 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 747 to address fingerprinting concerns 748 (). 750 Note that ALTSVC frame is preferred to Alt-Svc header field 751 (). 753 Incorporate ALTSRV frame 754 (). 756 Moved definition of status code 421 to HTTP/2. 758 Partly resolved . 760 Authors' Addresses 762 Mark Nottingham 763 Akamai 765 EMail: mnot@mnot.net 766 URI: https://www.mnot.net/ 768 Patrick McManus 769 Mozilla 771 EMail: mcmanus@ducksong.com 772 URI: https://mozillians.org/u/pmcmanus/ 774 Julian F. Reschke 775 greenbytes GmbH 777 EMail: julian.reschke@greenbytes.de 778 URI: https://greenbytes.de/tech/webdav/