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/