diff options
Diffstat (limited to 'doc/rfc/rfc7838.txt')
| -rw-r--r-- | doc/rfc/rfc7838.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7838.txt b/doc/rfc/rfc7838.txt new file mode 100644 index 0000000..e0f7280 --- /dev/null +++ b/doc/rfc/rfc7838.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Nottingham +Request for Comments: 7838 Akamai +Category: Standards Track P. McManus +ISSN: 2070-1721 Mozilla + J. Reschke + greenbytes + April 2016 + + + HTTP Alternative Services + +Abstract + + This document specifies "Alternative Services" for HTTP, which allow + an origin's resources to be authoritatively available at a separate + network location, possibly accessed with a different protocol + configuration. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7838. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Nottingham, et al. Standards Track [Page 1] + +RFC 7838 HTTP Alternative Services April 2016 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Notational Conventions .....................................3 + 2. Alternative Services Concepts ...................................3 + 2.1. Host Authentication ........................................5 + 2.2. Alternative Service Caching ................................6 + 2.3. Requiring Server Name Indication ...........................6 + 2.4. Using Alternative Services .................................6 + 3. The Alt-Svc HTTP Header Field ...................................8 + 3.1. Caching Alt-Svc Header Field Values .......................10 + 4. The ALTSVC HTTP/2 Frame ........................................11 + 5. The Alt-Used HTTP Header Field .................................13 + 6. The 421 (Misdirected Request) HTTP Status Code .................13 + 7. IANA Considerations ............................................13 + 7.1. Header Field Registrations ................................13 + 7.2. The ALTSVC HTTP/2 Frame Type ..............................14 + 7.3. Alt-Svc Parameter Registry ................................14 + 7.3.1. Procedure ..........................................14 + 7.3.2. Registrations ......................................15 + 8. Internationalization Considerations ............................15 + 9. Security Considerations ........................................15 + 9.1. Changing Ports ............................................15 + 9.2. Changing Hosts ............................................15 + 9.3. Changing Protocols ........................................16 + 9.4. Tracking Clients Using Alternative Services ...............17 + 9.5. Confusion regarding Request Scheme ........................17 + 10. References ....................................................18 + 10.1. Normative References .....................................18 + 10.2. Informative References ...................................19 + Acknowledgements ..................................................19 + Authors' Addresses ................................................20 + +1. Introduction + + HTTP [RFC7230] conflates the identification of resources with their + location. In other words, "http://" and "https://" URIs are used to + both name and find things to interact with. + + In some cases, it is desirable to separate identification and + location in HTTP; keeping the same identifier for a resource, but + interacting with it at a different location on the network. + + For example: + + o An origin server might wish to redirect a client to a different + server when it is under load, or it has found a server in a + location that is more local to the client. + + + +Nottingham, et al. Standards Track [Page 2] + +RFC 7838 HTTP Alternative Services April 2016 + + + o An origin server might wish to offer access to its resources using + a new protocol, such as HTTP/2 [RFC7540], or one using improved + security, such as Transport Layer Security (TLS) [RFC5246]. + + o An origin server might wish to segment its clients into groups of + capabilities, such as those supporting Server Name Indication + (SNI) (Section 3 of [RFC6066]), for operational purposes. + + This specification defines a new concept in HTTP, "Alternative + Services", that allows an origin server to nominate additional means + of interacting with it on the network. It defines a general + framework for this in Section 2, along with specific mechanisms for + advertising their existence using HTTP header fields (Section 3) or + HTTP/2 frames (Section 4), plus a way to indicate that an alternative + service was used (Section 5). + + It also endorses the status code 421 (Misdirected Request) + (Section 6) that origin servers or their nominated alternatives can + use to indicate that they are not authoritative for a given origin, + in cases where the wrong location is used. + +1.1. Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document uses the Augmented BNF defined in [RFC5234] and updated + by [RFC7405] along with the "#rule" extension defined in Section 7 of + [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and + [RFC7234]: + + OWS = <OWS, see [RFC7230], Section 3.2.3> + delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1> + port = <port, see [RFC7230], Section 2.7> + quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> + token = <token, see [RFC7230], Section 3.2.6> + uri-host = <uri-host, see [RFC7230], Section 2.7> + +2. Alternative Services Concepts + + This specification defines a new concept in HTTP, the "Alternative + Service". When an origin [RFC6454] has resources that are accessible + through a different protocol/host/port combination, it is said to + have an alternative service available. + + + + + + +Nottingham, et al. Standards Track [Page 3] + +RFC 7838 HTTP Alternative Services April 2016 + + + An alternative service can be used to interact with the resources on + an origin server at a separate location on the network, possibly + using a different protocol configuration. Alternative services are + considered authoritative for an origin's resources, in the sense of + [RFC7230], Section 9.1. + + For example, an origin: + + ("http", "www.example.com", "80") + + might declare that its resources are also accessible at the + alternative service: + + ("h2", "new.example.com", "81") + + By their nature, alternative services are explicitly at the + granularity of an origin; they cannot be selectively applied to + resources within an origin. + + Alternative services do not replace or change the origin for any + given resource; in general, they are not visible to the software + "above" the access mechanism. The alternative service is essentially + alternative routing information that can also be used to reach the + origin in the same way that DNS CNAME or SRV records define routing + information at the name resolution level. Each origin maps to a set + of these routes -- the default route is derived from the origin + itself and the other routes are introduced based on alternative- + service information. + + Furthermore, it is important to note that the first member of an + alternative service tuple is different from the "scheme" component of + an origin; it is more specific, identifying not only the major + version of the protocol being used, but potentially the communication + options for that protocol as well. + + This means that clients using an alternative service can change the + host, port, and protocol that they are using to fetch resources, but + these changes MUST NOT be propagated to the application that is using + HTTP; from that standpoint, the URI being accessed and all + information derived from it (scheme, host, and port) are the same as + before. + + Importantly, this includes its security context; in particular, when + TLS [RFC5246] is used to authenticate, the alternative service will + need to present a certificate for the origin's host name, not that of + the alternative. Likewise, the Host header field ([RFC7230], + Section 5.4) is still derived from the origin, not the alternative + service (just as it would if a CNAME were being used). + + + +Nottingham, et al. Standards Track [Page 4] + +RFC 7838 HTTP Alternative Services April 2016 + + + The changes MAY, however, be made visible in debugging tools, + consoles, etc. + + Formally, an alternative service is identified by the combination of: + + o An Application Layer Protocol Negotiation (ALPN) protocol name, as + per [RFC7301] + + o A host, as per [RFC3986], Section 3.2.2 + + o A port, as per [RFC3986], Section 3.2.3 + + The ALPN protocol name is used to identify the application protocol + or suite of protocols used by the alternative service. Note that for + the purpose of this specification, an ALPN protocol name implicitly + includes TLS in the suite of protocols it identifies, unless + specified otherwise in its definition. In particular, the ALPN name + "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 + over TLS. + + Additionally, each alternative service MUST have a freshness + lifetime, expressed in seconds (see Section 2.2). + + There are many ways that a client could discover the alternative + service(s) associated with an origin. This document describes two + such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the + "ALTSVC" HTTP/2 frame type (Section 4). + + The remainder of this section describes requirements that are common + to alternative services, regardless of how they are discovered. + +2.1. Host Authentication + + Clients MUST have reasonable assurances that the alternative service + is under control of and valid for the whole origin. This mitigates + the attack described in Section 9.2. + + For the purposes of this document, "reasonable assurances" can be + established through use of a TLS-based protocol with the certificate + checks defined in [RFC2818]. Clients MAY impose additional criteria + for establishing reasonable assurances. + + For example, if the origin's host is "www.example.com" and an + alternative is offered on "other.example.com" with the "h2" protocol, + and the certificate offered is valid for "www.example.com", the + client can use the alternative. However, if either is offered with + the "h2c" protocol, the client cannot use it, because there is no + + + + +Nottingham, et al. Standards Track [Page 5] + +RFC 7838 HTTP Alternative Services April 2016 + + + mechanism (at the time of the publication of this specification) in + that protocol to establish the relationship between the origin and + the alternative. + +2.2. Alternative Service Caching + + Mechanisms for discovering alternative services also associate a + freshness lifetime with them; for example, the Alt-Svc header field + uses the "ma" parameter. + + Clients can choose to use an alternative service instead of the + origin at any time when it is considered fresh; see Section 2.4 for + specific recommendations. + + Clients with existing connections to an alternative service do not + need to stop using it when its freshness lifetime ends; the caching + mechanism is intended for limiting how long an alternative service + can be used for establishing new connections, not limiting the use of + existing ones. + + Alternative services are fully authoritative for the origin in + question, including the ability to clear or update cached alternative + service entries, extend freshness lifetimes, and any other authority + the origin server would have. + + When alternative services are used to send a client to the most + optimal server, a change in network configuration can result in + cached values becoming suboptimal. Therefore, clients SHOULD remove + from cache all alternative services that lack the "persist" flag with + the value "1" when they detect such a change, when information about + network state is available. + +2.3. Requiring Server Name Indication + + A client MUST NOT use a TLS-based alternative service unless the + client supports TLS Server Name Indication (SNI). This supports the + conservation of IP addresses on the alternative service host. + + Note that the SNI information provided in TLS by the client will be + that of the origin, not the alternative (as will the Host HTTP header + field value). + +2.4. Using Alternative Services + + By their nature, alternative services are OPTIONAL: clients do not + need to use them. However, it is advantageous for clients to behave + in a predictable way when alternative services are used by servers, + to aid in purposes like load balancing. + + + +Nottingham, et al. Standards Track [Page 6] + +RFC 7838 HTTP Alternative Services April 2016 + + + Therefore, if a client supporting this specification becomes aware of + an alternative service, the client SHOULD use that alternative + service for all requests to the associated origin as soon as it is + available, provided the alternative service information is fresh + (Section 2.2) and the security properties of the alternative service + protocol are desirable, as compared to the existing connection. A + viable alternative service is then treated in every way as the + origin; this includes the ability to advertise alternative services. + + If a client becomes aware of multiple alternative services, it + chooses the most suitable according to its own criteria, keeping + security properties in mind. For example, an origin might advertise + multiple alternative services to notify clients of support for + multiple versions of HTTP. + + A client configured to use a proxy for a given request SHOULD NOT + directly connect to an alternative service for this request, but + instead route it through that proxy. + + When a client uses an alternative service for a request, it can + indicate this to the server using the Alt-Used header field + (Section 5). + + The client does not need to block requests on any existing + connection; it can be used until the alternative connection is + established. However, if the security properties of the existing + connection are weak (for example, cleartext HTTP/1.1), then it might + make sense to block until the new connection is fully available in + order to avoid information leakage. + + Furthermore, if the connection to the alternative service fails or is + unresponsive, the client MAY fall back to using the origin or another + alternative service. Note, however, that this could be the basis of + a downgrade attack, thus losing any enhanced security properties of + the alternative service. If the connection to the alternative + service does not negotiate the expected protocol (for example, ALPN + fails to negotiate h2, or an Upgrade request to h2c is not accepted), + the connection to the alternative service MUST be considered to have + failed. + + + + + + + + + + + + +Nottingham, et al. Standards Track [Page 7] + +RFC 7838 HTTP Alternative Services April 2016 + + +3. The Alt-Svc HTTP Header Field + + An HTTP(S) origin server can advertise the availability of + alternative services to clients by adding an Alt-Svc header field to + responses. + + Alt-Svc = clear / 1#alt-value + clear = %s"clear"; "clear", case-sensitive + alt-value = alternative *( OWS ";" OWS parameter ) + alternative = protocol-id "=" alt-authority + protocol-id = token ; percent-encoded ALPN protocol name + alt-authority = quoted-string ; containing [ uri-host ] ":" port + parameter = token "=" ( token / quoted-string ) + + The field value consists either of a list of values, each of which + indicates one alternative service, or the keyword "clear". + + A field value containing the special value "clear" indicates that the + origin requests all alternatives for that origin to be invalidated + (including those specified in the same response, in case of an + invalid reply containing both "clear" and alternative services). + + ALPN protocol names are octet sequences with no additional + constraints on format. Octets not allowed in tokens ([RFC7230], + Section 3.2.6) MUST be percent-encoded as per Section 2.1 of + [RFC3986]. Consequently, the octet representing the percent + character "%" (hex 25) MUST be percent-encoded as well. + + In order to have precisely one way to represent any ALPN protocol + name, the following additional constraints apply: + + 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if + they are valid token characters except "%", and + + 2. When using percent-encoding, uppercase hex digits MUST be used. + + With these constraints, recipients can apply simple string comparison + to match protocol identifiers. + + The "alt-authority" component consists of an OPTIONAL uri-host + ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port + number. + + For example: + + Alt-Svc: h2=":8000" + + + + + +Nottingham, et al. Standards Track [Page 8] + +RFC 7838 HTTP Alternative Services April 2016 + + + This indicates the "h2" protocol ([RFC7540]) on the same host using + the indicated port 8000. + + An example involving a change of host: + + Alt-Svc: h2="new.example.org:80" + + This indicates the "h2" protocol on the host "new.example.org", + running on port 80. Note that the "quoted-string" syntax needs to be + used because ":" is not an allowed character in "token". + + Examples for protocol name escaping: + + +--------------------+-------------+---------------------+ + | ALPN protocol name | protocol-id | Note | + +--------------------+-------------+---------------------+ + | h2 | h2 | No escaping needed | + +--------------------+-------------+---------------------+ + | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | + +--------------------+-------------+---------------------+ + | x%y | x%25y | "%" needs escaping | + +--------------------+-------------+---------------------+ + + Alt-Svc MAY occur in any HTTP response message, regardless of the + status code. Note that recipients of Alt-Svc can ignore the header + field (and are required to in some situations; see Sections 2.1 and + 6). + + The Alt-Svc field value can have multiple values: + + Alt-Svc: h2="alt.example.com:8000", h2=":443" + + When multiple values are present, the order of the values reflects + the server's preference (with the first value being the most + preferred alternative). + + The value(s) advertised by Alt-Svc can be used by clients to open a + new connection to an alternative service. Subsequent requests can + start using this new connection immediately or can continue using the + existing connection while the new connection is created. + + When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC + frame (Section 4). A single ALTSVC frame can be sent for a + connection; a new frame is not needed for every request. Note that, + despite this recommendation, Alt-Svc header fields remain valid in + responses delivered over HTTP/2. + + + + + +Nottingham, et al. Standards Track [Page 9] + +RFC 7838 HTTP Alternative Services April 2016 + + + Each "alt-value" is followed by an OPTIONAL semicolon-separated list + of additional parameters, each such "parameter" comprising a name and + a value. + + This specification defines two parameters: "ma" and "persist", + defined in Section 3.1. Unknown parameters MUST be ignored. That + is, the values (alt-value) they appear in MUST be processed as if the + unknown parameter was not present. + + New parameters can be defined in extension specifications (see + Section 7.3 for registration details). + + Note that all field elements that allow "quoted-string" syntax MUST + be processed as per Section 3.2.6 of [RFC7230]. + +3.1. Caching Alt-Svc Header Field Values + + When an alternative service is advertised using Alt-Svc, it is + considered fresh for 24 hours from generation of the message. This + can be modified with the "ma" (max-age) parameter. + + Syntax: + + ma = delta-seconds; see [RFC7234], Section 1.2.1 + + The delta-seconds value indicates the number of seconds since the + response was generated for which the alternative service is + considered fresh. + + Alt-Svc: h2=":443"; ma=3600 + + See Section 4.2.3 of [RFC7234] for details on determining the + response age. + + For example, a response: + + HTTP/1.1 200 OK + Content-Type: text/html + Cache-Control: max-age=600 + Age: 30 + Alt-Svc: h2=":8000"; ma=60 + + indicates that an alternative service is available and usable for the + next 60 seconds. However, the response has already been cached for + 30 seconds (as per the Age header field value); therefore, the + alternative service is only fresh for the 30 seconds from when this + response was received, minus estimated transit time. + + + + +Nottingham, et al. Standards Track [Page 10] + +RFC 7838 HTTP Alternative Services April 2016 + + + Note that the freshness lifetime for HTTP caching (here, 600 seconds) + does not affect caching of Alt-Svc values. + + When an Alt-Svc response header field is received from an origin, its + value invalidates and replaces all cached alternative services for + that origin. + + By default, cached alternative services will be cleared when the + client detects a network change. Alternative services that are + intended to be longer lived (such as those that are not specific to + the client access network) can carry the "persist" parameter with a + value "1" as a hint that the service is potentially useful beyond a + network configuration change. + + Syntax: + + persist = "1" + + For example: + + Alt-Svc: h2=":443"; ma=2592000; persist=1 + + This specification only defines a single value for "persist". + Clients MUST ignore "persist" parameters with values other than "1". + + See Section 2.2 for general requirements on caching alternative + services. + +4. The ALTSVC HTTP/2 Frame + + The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the + availability of an alternative service to an HTTP/2 client. + + The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints + that do not support this frame will ignore it (as per the + extensibility rules defined in Section 4.1 of [RFC7540]). + + An ALTSVC frame from a server to a client on a stream other than + stream 0 indicates that the conveyed alternative service is + associated with the origin of that stream. + + An ALTSVC frame from a server to a client on stream 0 indicates that + the conveyed alternative service is associated with the origin + contained in the Origin field of the frame. An association with an + origin that the client does not consider authoritative for the + current connection MUST be ignored. + + The ALTSVC frame type is 0xa (decimal 10). + + + +Nottingham, et al. Standards Track [Page 11] + +RFC 7838 HTTP Alternative Services April 2016 + + + +-------------------------------+-------------------------------+ + | Origin-Len (16) | Origin? (*) ... + +-------------------------------+-------------------------------+ + | Alt-Svc-Field-Value (*) ... + +---------------------------------------------------------------+ + + ALTSVC Frame Payload + + The ALTSVC frame contains the following fields: + + Origin-Len: An unsigned, 16-bit integer indicating the length, in + octets, of the Origin field. + + Origin: An OPTIONAL sequence of characters containing the ASCII + serialization of an origin ([RFC6454], Section 6.2) to which the + alternative service is applicable. + + Alt-Svc-Field-Value: A sequence of octets (length determined by + subtracting the length of all preceding fields from the frame + length) containing a value identical to the Alt-Svc field value + defined in Section 3 (ABNF production "Alt-Svc"). + + The ALTSVC frame does not define any flags. + + The ALTSVC frame is intended for receipt by clients. A device acting + as a server MUST ignore it. + + An ALTSVC frame on stream 0 with empty (length 0) "Origin" + information is invalid and MUST be ignored. An ALTSVC frame on a + stream other than stream 0 containing non-empty "Origin" information + is invalid and MUST be ignored. + + The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT + forward ALTSVC frames, though it can use the information contained in + ALTSVC frames in forming new ALTSVC frames to send to its own + clients. + + Receiving an ALTSVC frame is semantically equivalent to receiving an + Alt-Svc header field. As a result, the ALTSVC frame causes + alternative services for the corresponding origin to be replaced. + Note that it would be unwise to mix the use of Alt-Svc header fields + with the use of ALTSVC frames, as the sequence of receipt might be + hard to predict. + + + + + + + + +Nottingham, et al. Standards Track [Page 12] + +RFC 7838 HTTP Alternative Services April 2016 + + +5. The Alt-Used HTTP Header Field + + The Alt-Used header field is used in requests to identify the + alternative service in use, just as the Host header field + (Section 5.4 of [RFC7230]) identifies the host and port of the + origin. + + Alt-Used = uri-host [ ":" port ] + + Alt-Used is intended to allow alternative services to detect loops, + differentiate traffic for purposes of load balancing, and generally + to ensure that it is possible to identify the intended destination of + traffic, since introducing this information after a protocol is in + use has proven to be problematic. + + When using an alternative service, clients SHOULD include an Alt-Used + header field in all requests. + + For example: + + GET /thing HTTP/1.1 + Host: origin.example.com + Alt-Used: alternate.example.net + +6. The 421 (Misdirected Request) HTTP Status Code + + The 421 (Misdirected Request) status code is defined in Section 9.1.2 + of [RFC7540] to indicate that the current server instance is not + authoritative for the requested resource. This can be used to + indicate that an alternative service is not authoritative; see + Section 2). + + Clients receiving 421 (Misdirected Request) from an alternative + service MUST remove the corresponding entry from its alternative + service cache (see Section 2.2) for that origin. Regardless of the + idempotency of the request method, they MAY retry the request, either + at another alternative server, or at the origin. + + An Alt-Svc header field in a 421 (Misdirected Request) response MUST + be ignored. + +7. IANA Considerations + +7.1. Header Field Registrations + + HTTP header fields are registered within the "Message Headers" + registry maintained at <https://www.iana.org/assignments/message- + headers/>. + + + +Nottingham, et al. Standards Track [Page 13] + +RFC 7838 HTTP Alternative Services April 2016 + + + This document defines the following HTTP header fields, so their + associated registry entries have been added according to the + permanent registrations below (see [BCP90]): + + +-------------------+----------+----------+------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+------------+ + | Alt-Svc | http | standard | Section 3 | + | Alt-Used | http | standard | Section 5 | + +-------------------+----------+----------+------------+ + + The change controller is: "IETF (iesg@ietf.org) -- Internet + Engineering Task Force". + +7.2. The ALTSVC HTTP/2 Frame Type + + This document registers the ALTSVC frame type in the "HTTP/2 Frame + Type" registry ([RFC7540], Section 11.2). + + Frame Type: ALTSVC + + Code: 0xa + + Specification: Section 4 of this document + +7.3. Alt-Svc Parameter Registry + + The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" + defines the name space for parameters. It has been created and will + be maintained at <http://www.iana.org/assignments/http-alt-svc- + parameters>. + +7.3.1. Procedure + + A registration MUST include the following fields: + + o Parameter Name + + o Pointer to specification text + + Values to be added to this name space require Expert Review (see + [RFC5226], Section 4.1). + + + + + + + + + +Nottingham, et al. Standards Track [Page 14] + +RFC 7838 HTTP Alternative Services April 2016 + + +7.3.2. Registrations + + The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" + has been populated with the registrations below: + + +-------------------+--------------+ + | Alt-Svc Parameter | Reference | + +-------------------+--------------+ + | ma | Section 3.1 | + | persist | Section 3.1 | + +-------------------+--------------+ + +8. Internationalization Considerations + + An internationalized domain name that appears in either the header + field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed + using A-labels ([RFC5890], Section 2.3.2.1). + +9. Security Considerations + +9.1. Changing Ports + + Using an alternative service implies accessing an origin's resources + on an alternative port, at a minimum. Therefore, an attacker that + can inject alternative services and listen at the advertised port is + able to hijack an origin. On certain servers, it is normal for users + to be able to control some personal pages available on a shared port + and also to accept requests on less-privileged ports. + + For example, an attacker that can add HTTP response header fields to + some pages can redirect traffic for an entire origin to a different + port on the same host using the Alt-Svc header field; if that port is + under the attacker's control, they can thus masquerade as the HTTP + server. + + This risk is mitigated by the requirements in Section 2.1. + + On servers, this risk can also be reduced by restricting the ability + to advertise alternative services, and restricting who can open a + port for listening on that host. + +9.2. Changing Hosts + + When the host is changed due to the use of an alternative service, + this presents an opportunity for attackers to hijack communication to + an origin. + + + + + +Nottingham, et al. Standards Track [Page 15] + +RFC 7838 HTTP Alternative Services April 2016 + + + For example, if an attacker can convince a user agent to send all + traffic for "innocent.example.org" to "evil.example.com" by + successfully associating it as an alternative service, they can + masquerade as that origin. This can be done locally (see mitigations + in Section 9.1) or remotely (e.g., by an intermediary as a man-in- + the-middle attack). + + This is the reason for the requirement in Section 2.1 that clients + have reasonable assurances that the alternative service is under + control of and valid for the whole origin; for example, presenting a + certificate for the origin proves that the alternative service is + authorized to serve traffic for the origin. + + Note that this assurance is only as strong as the method used to + authenticate the alternative service. In particular, when TLS + authentication is used to do so, there are well-known exploits to + make an attacker's certificate appear as legitimate. + + Alternative services could be used to persist such an attack. For + example, an intermediary could man-in-the-middle TLS-protected + communication to a target and then direct all traffic to an + alternative service with a large freshness lifetime so that the user + agent still directs traffic to the attacker even when not using the + intermediary. + + Implementations MUST perform any certificate-pinning validation (such + as [RFC7469]) on alternative services just as they would on direct + connections to the origin. Implementations might also choose to add + other requirements around which certificates are acceptable for + alternative services. + +9.3. Changing Protocols + + When the ALPN protocol is changed due to the use of an alternative + service, the security properties of the new connection to the origin + can be different from that of the "normal" connection to the origin, + because the protocol identifier itself implies this. + + For example, if an "https://" URI has a protocol advertised that does + not use some form of end-to-end encryption (most likely, TLS), this + violates the expectations for security that the URI scheme implies. + Therefore, clients cannot use alternative services blindly, but + instead evaluate the option(s) presented to ensure that security + requirements and expectations of specifications, implementations, and + end users are met. + + + + + + +Nottingham, et al. Standards Track [Page 16] + +RFC 7838 HTTP Alternative Services April 2016 + + +9.4. Tracking Clients Using Alternative Services + + Choosing an alternative service implies connecting to a new, server- + supplied host name. By using unique names, servers could conceivably + track client requests. Such tracking could follow users across + multiple networks, when the "persist" flag is used. + + Clients that wish to prevent requests from being correlated can + decide not to use alternative services for multiple requests that + would not otherwise be allowed to be correlated. + + In a user agent, any alternative service information MUST be removed + when origin-specific data is cleared (typically, when cookies + [RFC6265] are cleared). + +9.5. Confusion regarding Request Scheme + + Some server-side HTTP applications make assumptions about security + based upon connection context; for example, equating being served + upon port 443 with the use of an "https://" URI and the various + security properties that implies. + + This affects not only the security properties of the connection + itself, but also the state of the client at the other end of it; for + example, a Web browser treats "https://" URIs differently than + "http://" URIs in many ways, not just for purposes of protocol + handling. + + Since one of the uses of Alternative Services is to allow a + connection to be migrated to a different protocol and port, these + applications can become confused about the security properties of a + given connection, sending information (for example, cookies and + content) that is intended for a secure context (such as an "https://" + URI) to a client that is not treating it as one. + + This risk can be mitigated in servers by using the URI scheme + explicitly carried by the protocol (such as ":scheme" in HTTP/2 or + the "absolute form" of the request target in HTTP/1.1) as an + indication of security context, instead of other connection + properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). + + When the protocol does not explicitly carry the scheme (as is usually + the case for HTTP/1.1 over TLS), servers can mitigate this risk by + either assuming that all requests have an insecure context, or by + refraining from advertising alternative services for insecure schemes + (for example, HTTP). + + + + + +Nottingham, et al. Standards Track [Page 17] + +RFC 7838 HTTP Alternative Services April 2016 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + <http://www.rfc-editor.org/info/rfc2818>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <http://www.rfc-editor.org/info/rfc5234>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <http://www.rfc-editor.org/info/rfc5890>. + + [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: + Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, + January 2011, <http://www.rfc-editor.org/info/rfc6066>. + + [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, + DOI 10.17487/RFC6454, December 2011, + <http://www.rfc-editor.org/info/rfc6454>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <http://www.rfc-editor.org/info/rfc7230>. + + + + + + +Nottingham, et al. Standards Track [Page 18] + +RFC 7838 HTTP Alternative Services April 2016 + + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, DOI 10.17487/RFC7234, June 2014, + <http://www.rfc-editor.org/info/rfc7234>. + + [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, + "Transport Layer Security (TLS) Application-Layer Protocol + Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, + July 2014, <http://www.rfc-editor.org/info/rfc7301>. + + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", + RFC 7405, DOI 10.17487/RFC7405, December 2014, + <http://www.rfc-editor.org/info/rfc7405>. + + [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext + Transfer Protocol version 2", RFC 7540, + DOI 10.17487/RFC7540, May 2015, + <http://www.rfc-editor.org/info/rfc7540>. + +10.2. Informative References + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004, <http://www.rfc-editor.org/info/bcp90>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + DOI 10.17487/RFC6265, April 2011, + <http://www.rfc-editor.org/info/rfc6265>. + + [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April + 2015, <http://www.rfc-editor.org/info/rfc7469>. + +Acknowledgements + + Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik + Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, + Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard + Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their + feedback and suggestions. + + The Alt-Svc header field was influenced by the design of the + Alternate-Protocol header field in SPDY. + + + +Nottingham, et al. Standards Track [Page 19] + +RFC 7838 HTTP Alternative Services April 2016 + + +Authors' Addresses + + Mark Nottingham + Akamai + + Email: mnot@mnot.net + URI: https://www.mnot.net/ + + + Patrick McManus + Mozilla + + Email: mcmanus@ducksong.com + URI: https://mozillians.org/u/pmcmanus/ + + + Julian F. Reschke + greenbytes GmbH + + Email: julian.reschke@greenbytes.de + URI: https://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nottingham, et al. Standards Track [Page 20] + |