draft-ietf-httpbis-alt-svc-08.txt   draft-ietf-httpbis-alt-svc-09.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track P. McManus Intended status: Standards Track P. McManus
Expires: March 23, 2016 Mozilla Expires: May 20, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
September 20, 2015 November 17, 2015
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-08 draft-ietf-httpbis-alt-svc-09
Abstract Abstract
This document specifies "alternative services" for HTTP, which allow This document specifies "alternative services" for HTTP, which allow
an origin's resources to be authoritatively available at a separate an origin's resources to be authoritatively available at a separate
network location, possibly accessed with a different protocol network location, possibly accessed with a different protocol
configuration. configuration.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 23, 2016. This Internet-Draft will expire on May 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5
2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7
2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7
2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7
2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8
3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 8 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9
3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11
4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12
5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 13 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 13
6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14
7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15
7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15
7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
8. Internationalization Considerations . . . . . . . . . . . . . 15 8. Internationalization Considerations . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
9.4. Tracking Clients Using Alternative Services . . . . . . . 17 9.4. Tracking Clients Using Alternative Services . . . . . . . 17
9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 17 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 19 publication) . . . . . . . . . . . . . . . . . . . . 20
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 19 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 19 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20
A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 19 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20
A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 19 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 20 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 20 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 20 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21
A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 20 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 21
A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 21 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 22
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
HTTP [RFC7230] conflates the identification of resources with their HTTP [RFC7230] conflates the identification of resources with their
location. In other words, "http://" (and "https://") URLs are used location. In other words, "http://" (and "https://") URLs are used
to both name and find things to interact with. to both name and find things to interact with.
In some cases, it is desirable to separate identification and In some cases, it is desirable to separate identification and
location in HTTP; keeping the same identifier for a resource, but location in HTTP; keeping the same identifier for a resource, but
interacting with it at a different location on the network. interacting with it at a different location on the network.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
By their nature, alternative services are explicitly at the By their nature, alternative services are explicitly at the
granularity of an origin; i.e., they cannot be selectively applied to granularity of an origin; i.e., they cannot be selectively applied to
resources within an origin. resources within an origin.
Alternative services do not replace or change the origin for any Alternative services do not replace or change the origin for any
given resource; in general, they are not visible to the software given resource; in general, they are not visible to the software
"above" the access mechanism. The alternative service is essentially "above" the access mechanism. The alternative service is essentially
alternative routing information that can also be used to reach the alternative routing information that can also be used to reach the
origin in the same way that DNS CNAME or SRV records define routing 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 information at the name resolution level. Each origin maps to a set
of these routes -- the default route is derived from thr origin of these routes -- the default route is derived from the origin
itself and the other routes are introduced based on alternative- itself and the other routes are introduced based on alternative-
protocol information. protocol information.
Furthermore, it is important to note that the first member of an Furthermore, it is important to note that the first member of an
alternative service tuple is different from the "scheme" component of alternative service tuple is different from the "scheme" component of
an origin; it is more specific, identifying not only the major an origin; it is more specific, identifying not only the major
version of the protocol being used, but potentially communication version of the protocol being used, but potentially communication
options for that protocol. options for that protocol.
This means that clients using an alternative service can change the This means that clients using an alternative service can change the
skipping to change at page 7, line 27 skipping to change at page 7, line 27
offered with the "h2c" protocol, the client cannot use it, because offered with the "h2c" protocol, the client cannot use it, because
there is no mechanism in that protocol to establish strong server there is no mechanism in that protocol to establish strong server
authentication. authentication.
2.2. Alternative Service Caching 2.2. Alternative Service Caching
Mechanisms for discovering alternative services also associate a Mechanisms for discovering alternative services also associate a
freshness lifetime with them; for example, the Alt-Svc header field freshness lifetime with them; for example, the Alt-Svc header field
uses the "ma" parameter. uses the "ma" parameter.
Clients MAY choose to use an alternative service instead of the 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 origin at any time when it is considered fresh; see Section 2.4 for
specific recommendations. specific recommendations.
Clients with existing connections to an alternative service do not Clients with existing connections to an alternative service do not
need to stop using it when its freshness lifetime ends; i.e., the need to stop using it when its freshness lifetime ends; i.e., the
caching mechanism is intended for limiting how long an alternative caching mechanism is intended for limiting how long an alternative
service can be used for establishing new connections, not limiting service can be used for establishing new connections, not limiting
the use of existing ones. 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 When alternative services are used to send a client to the most
optimal server, a change in network configuration can result in optimal server, a change in network configuration can result in
cached values becoming suboptimal. Therefore, clients SHOULD remove cached values becoming suboptimal. Therefore, clients SHOULD remove
from cache all alternative services that lack the "persist" flag with from cache all alternative services that lack the "persist" flag with
the value "1" when they detect such a change (when information about the value "1" when they detect such a change (when information about
network state is available). network state is available).
2.3. Requiring Server Name Indication 2.3. Requiring Server Name Indication
A client MUST only use a TLS-based alternative service if the client A client MUST only use a TLS-based alternative service if the client
skipping to change at page 8, line 14 skipping to change at page 8, line 19
2.4. Using Alternative Services 2.4. Using Alternative Services
By their nature, alternative services are OPTIONAL: clients do not By their nature, alternative services are OPTIONAL: clients do not
need to use them. However, it is advantageous for clients to behave need to use them. However, it is advantageous for clients to behave
in a predictable way when they are used by servers (e.g., for load in a predictable way when they are used by servers (e.g., for load
balancing). balancing).
Therefore, if a client becomes aware of an alternative service, the Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided that 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 security properties of the alternative service protocol are
desirable, as compared to the existing connection. desirable, as compared to the existing connection.
If a client becomes aware of multiple alternative services, it MAY If a client becomes aware of multiple alternative services, it MAY
choose the most suitable according to its own criteria (again, choose the most suitable according to its own criteria (again,
keeping security properties in mind). For example, an origin might keeping security properties in mind). For example, an origin might
advertise multiple alternative services to notify clients of support advertise multiple alternative services to notify clients of support
for multiple versions of HTTP; or, an alternative service might for multiple versions of HTTP; or, an alternative service might
itself advertise an alternative. itself advertise an alternative.
skipping to change at page 8, line 44 skipping to change at page 8, line 50
connection; it can be used until the alternative connection is connection; it can be used until the alternative connection is
established. However, if the security properties of the existing established. However, if the security properties of the existing
connection are weak (e.g. cleartext HTTP/1.1) then it might make connection are weak (e.g. cleartext HTTP/1.1) then it might make
sense to block until the new connection is fully available in order sense to block until the new connection is fully available in order
to avoid information leakage. to avoid information leakage.
Furthermore, if the connection to the alternative service fails or is Furthermore, if the connection to the alternative service fails or is
unresponsive, the client MAY fall back to using the origin or another unresponsive, the client MAY fall back to using the origin or another
alternative service. Note, however, that this could be the basis of alternative service. Note, however, that this could be the basis of
a downgrade attack, thus losing any enhanced security properties of a downgrade attack, thus losing any enhanced security properties of
the alternative service. 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.
3. The Alt-Svc HTTP Header Field 3. The Alt-Svc HTTP Header Field
An HTTP(S) origin server can advertise the availability of An HTTP(S) origin server can advertise the availability of
alternative services to clients by adding an Alt-Svc header field to alternative services to clients by adding an Alt-Svc header field to
responses. responses.
Alt-Svc = clear / 1#alt-value Alt-Svc = clear / 1#alt-value
clear = %x63.6C.65.61.72; "clear", case-sensitive clear = %x63.6C.65.61.72; "clear", case-sensitive
alt-value = alternative *( OWS ";" OWS parameter ) alt-value = alternative *( OWS ";" OWS parameter )
skipping to change at page 11, line 31 skipping to change at page 11, line 38
ma = delta-seconds ma = delta-seconds
See Section 4.2.3 of [RFC7234] for details of determining response See Section 4.2.3 of [RFC7234] for details of determining response
age. age.
For example, a response: For example, a response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Cache-Control: 600 Cache-Control: max-age=600
Age: 30 Age: 30
Alt-Svc: h2c=":8000"; ma=60 Alt-Svc: h2c=":8000"; ma=60
indicates that an alternative service is available and usable for the indicates that an alternative service is available and usable for the
next 60 seconds. However, the response has already been cached for next 60 seconds. However, the response has already been cached for
30 seconds (as per the Age header field value), so therefore the 30 seconds (as per the Age header field value), so therefore the
alternative service is only fresh for the 30 seconds from when this alternative service is only fresh for the 30 seconds from when this
response was received, minus estimated transit time. response was received, minus estimated transit time.
Note that the freshness lifetime for HTTP caching (here, 600 seconds) Note that the freshness lifetime for HTTP caching (here, 600 seconds)
skipping to change at page 14, line 11 skipping to change at page 14, line 15
As the Alt-Used header field might be used by the server for tracking As the Alt-Used header field might be used by the server for tracking
the client, a client MAY choose not to include it in its requests for the client, a client MAY choose not to include it in its requests for
protecting its privacy (see Section 9.4). protecting its privacy (see Section 9.4).
For example: For example:
GET /thing HTTP/1.1 GET /thing HTTP/1.1
Host: origin.example.com Host: origin.example.com
Alt-Used: alternate.example.net Alt-Used: alternate.example.net
The extension parameters (ext-param) are reserved for future use;
specifications that want to define an extension will need to update
this document (and ought to introduce an extension registry).
6. The 421 Misdirected Request HTTP Status Code 6. The 421 Misdirected Request HTTP Status Code
The 421 (Misdirected Request) status code is defined in Section 9.1.2 The 421 (Misdirected Request) status code is defined in Section 9.1.2
of [RFC7540] to indicate that the current server instance is not of [RFC7540] to indicate that the current server instance is not
authoritative for the requested resource. This can be used to authoritative for the requested resource. This can be used to
indicate that an alternative service is not authoritative; see indicate that an alternative service is not authoritative; see
Section 2). Section 2).
Clients receiving 421 (Misdirected Request) from an alternative Clients receiving 421 (Misdirected Request) from an alternative
service MUST remove the corresponding entry from its alternative service MUST remove the corresponding entry from its alternative
skipping to change at page 15, line 31 skipping to change at page 15, line 31
<http://www.iana.org/assignments/http-alt-svc-parameters>. <http://www.iana.org/assignments/http-alt-svc-parameters>.
7.3.1. Procedure 7.3.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Parameter Name o Parameter Name
o Pointer to specification text o Pointer to specification text
Values to be added to this name space require IETF Review (see Values to be added to this name space require Expert Review (see
[RFC5226], Section 4.1). [RFC5226], Section 4.1).
7.3.2. Registrations 7.3.2. Registrations
The HTTP Alt-Svc Parameter Registry is to be populated with the The HTTP Alt-Svc Parameter Registry is to be populated with the
registrations below: registrations below:
+-------------------+-------------+ +-------------------+-------------+
| Alt-Svc Parameter | Reference | | Alt-Svc Parameter | Reference |
+-------------------+-------------+ +-------------------+-------------+
skipping to change at page 16, line 12 skipping to change at page 16, line 12
field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
using A-labels ([RFC5890], Section 2.3.2.1). using A-labels ([RFC5890], Section 2.3.2.1).
9. Security Considerations 9. Security Considerations
9.1. Changing Ports 9.1. Changing Ports
Using an alternative service implies accessing an origin's resources Using an alternative service implies accessing an origin's resources
on an alternative port, at a minimum. An attacker that can inject on an alternative port, at a minimum. An attacker that can inject
alternative services and listen at the advertised port is therefore alternative services and listen at the advertised port is therefore
able to hijack an origin. 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 to requests on less-privileged ports.
For example, an attacker that can add HTTP response header fields can For example, an attacker that can add HTTP response header fields to
redirect traffic to a different port on the same host using the Alt- some pages can redirect traffic for an entire origin to a different
Svc header field; if that port is under the attacker's control, they port on the same host using the Alt-Svc header field; if that port is
can thus masquerade as the HTTP server. under the attacker's control, they can thus masquerade as the HTTP
server.
This risk can be mitigated by restricting the ability to advertise On servers, this risk can be reduced by restricting the ability to
alternative services, and restricting who can open a port for advertise alternative services, and restricting who can open a port
listening on that host. for listening on that host. Clients can reduce this risk by imposing
stronger requirements (e.g. strong authentication) when moving from
System Ports to User or Dynamic Ports, or from User Ports to Dynamic
Ports, as defined in Section 6 of [RFC6335].
It is always valid for a client to ignore an alternative service
advertisement which does not meet its implementation-specific
security requirements. Servers can increase the likelihood of
clients using the alternative service by providing strong
authentication even when not required.
9.2. Changing Hosts 9.2. Changing Hosts
When the host is changed due to the use of an alternative service, it When the host is changed due to the use of an alternative service, it
presents an opportunity for attackers to hijack communication to an presents an opportunity for attackers to hijack communication to an
origin. origin.
For example, if an attacker can convince a user agent to send all For example, if an attacker can convince a user agent to send all
traffic for "innocent.example.org" to "evil.example.com" by traffic for "innocent.example.org" to "evil.example.com" by
successfully associating it as an alternative service, they can successfully associating it as an alternative service, they can
skipping to change at page 17, line 5 skipping to change at page 17, line 17
known exploits to make an attacker's certificate appear as known exploits to make an attacker's certificate appear as
legitimate. legitimate.
Alternative services could be used to persist such an attack; for Alternative services could be used to persist such an attack; for
example, an intermediary could man-in-the-middle TLS-protected example, an intermediary could man-in-the-middle TLS-protected
communication to a target, and then direct all traffic to an communication to a target, and then direct all traffic to an
alternative service with a large freshness lifetime, so that the user alternative service with a large freshness lifetime, so that the user
agent still directs traffic to the attacker even when not using the agent still directs traffic to the attacker even when not using the
intermediary. intermediary.
Implementations MUST perform any certificate-pinning validation (e.g.
[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 9.3. Changing Protocols
When the ALPN protocol is changed due to the use of an alternative When the ALPN protocol is changed due to the use of an alternative
service, the security properties of the new connection to the origin service, the security properties of the new connection to the origin
can be different from that of the "normal" connection to the origin, can be different from that of the "normal" connection to the origin,
because the protocol identifier itself implies this. because the protocol identifier itself implies this.
For example, if a "https://" URI has a protocol advertised that does For example, if a "https://" URI has a protocol advertised that does
not use some form of end-to-end encryption (most likely, TLS), it not use some form of end-to-end encryption (most likely, TLS), it
violates the expectations for security that the URI scheme implies. violates the expectations for security that the URI scheme implies.
skipping to change at page 17, line 38 skipping to change at page 18, line 7
Clients concerned by the additional fingerprinting can choose to Clients concerned by the additional fingerprinting can choose to
ignore alternative service advertisements. ignore alternative service advertisements.
In a user agent, any alternative service information MUST be removed In a user agent, any alternative service information MUST be removed
when origin-specific data is cleared (for instance, when cookies are when origin-specific data is cleared (for instance, when cookies are
cleared). cleared).
9.5. Confusion Regarding Request Scheme 9.5. Confusion Regarding Request Scheme
Alternative Services MUST NOT be advertised for a protocol that is Some server-side HTTP applications make assumptions about security
not designed to carry the scheme. In particular, HTTP/1.1 over TLS based upon connection context; for example, equating being served
cannot safely carry requests for http resources. upon port 443 with the use of a HTTPS URL (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 URLs differently than HTTP URLs
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 (e.g., cookies, content) that
is intended for a secure context (e.g., a HTTPS URL) to a client that
is not treating it as one.
This risk can be mitigated in servers by using the URL scheme
explicitly carried by the protocol (e.g., ":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 (e.g., 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 (such as HTTP).
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 19, line 16 skipping to change at page 20, line 7
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <http://www.rfc-editor.org/info/bcp90>. September 2004, <http://www.rfc-editor.org/info/bcp90>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008, RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", RFC 6335,
DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[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>.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-nottingham-httpbis-alt-svc-05 A.1. Since draft-nottingham-httpbis-alt-svc-05
This is the first version after adoption of This is the first version after adoption of
draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
only contains editorial changes. only contains editorial changes.
A.2. Since draft-ietf-httpbis-alt-svc-00 A.2. Since draft-ietf-httpbis-alt-svc-00
skipping to change at page 21, line 44 skipping to change at page 22, line 49
Alt-Svc header with 421 status Alt-Svc header with 421 status
(<https://github.com/httpwg/http-extensions/issues/75>). (<https://github.com/httpwg/http-extensions/issues/75>).
Incorporate several editorial improvements suggested by Mike Bishop Incorporate several editorial improvements suggested by Mike Bishop
(<https://github.com/httpwg/http-extensions/pull/77>, (<https://github.com/httpwg/http-extensions/pull/77>,
<https://github.com/httpwg/http-extensions/pull/78>). <https://github.com/httpwg/http-extensions/pull/78>).
Alt-Svc response header field in HTTP/2 frame Alt-Svc response header field in HTTP/2 frame
(<https://github.com/httpwg/http-extensions/issues/87>). (<https://github.com/httpwg/http-extensions/issues/87>).
A.10. Since draft-ietf-httpbis-alt-svc-08
Remove left over text about ext-params, applying to an earlier
version of Alt-Used (see
<https://github.com/httpwg/http-extensions/issues/34>).
Conflicts between Alt-Svc and ALPN
(<https://github.com/httpwg/http-extensions/issues/72>).
Elevation of privilege
(<https://github.com/httpwg/http-extensions/issues/73>).
Alternates of alternates
(<https://github.com/httpwg/http-extensions/issues/74>).
Alt-Svc and Cert Pinning
(<https://github.com/httpwg/http-extensions/issues/76>).
Using alt-svc on localhost (no change to spec, see
<https://github.com/httpwg/http-extensions/issues/89>).
IANA procedure for alt-svc parameters
(<https://github.com/httpwg/http-extensions/issues/96>).
Alt-svc from https (1.1) to https (1.1)
(<https://github.com/httpwg/http-extensions/issues/91>).
Alt-svc vs the ability to convey the scheme inside the protocol
(<https://github.com/httpwg/http-extensions/issues/92>).
Reconciling MAY/can vs. SHOULD
(<https://github.com/httpwg/http-extensions/issues/101>).
Typo in alt-svc caching example
(<https://github.com/httpwg/http-extensions/issues/117>).
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy
Podjarny, Herve Ruellan, Martin Thomson, Matthew Kerwin, Mike Bishop, Podjarny, Herve Ruellan, Martin Thomson, Matthew Kerwin, Mike Bishop,
Paul Hoffman, Richard Barnes, Stephen Farrell, Stephen Ludin, and Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell,
Will Chan for their feedback and suggestions. Stephen Ludin, and Will Chan for their feedback and suggestions.
The Alt-Svc header field was influenced by the design of the The Alt-Svc header field was influenced by the design of the
Alternate-Protocol header field in SPDY. Alternate-Protocol header field in SPDY.
Authors' Addresses Authors' Addresses
Mark Nottingham Mark Nottingham
Akamai Akamai
EMail: mnot@mnot.net EMail: mnot@mnot.net
 End of changes. 23 change blocks. 
42 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/