draft-ietf-httpbis-alt-svc-13.txt   draft-ietf-httpbis-alt-svc-14.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: September 2, 2016 Mozilla Expires: September 9, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
March 1, 2016 March 8, 2016
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-13 draft-ietf-httpbis-alt-svc-14
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 48 skipping to change at page 1, line 48
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 September 2, 2016. This Internet-Draft will expire on September 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 7, line 13 skipping to change at page 7, line 13
to alternative services, regardless of how they are discovered. to alternative services, regardless of how they are discovered.
2.1. Host Authentication 2.1. Host Authentication
Clients MUST have reasonable assurances that the alternative service Clients MUST have reasonable assurances that the alternative service
is under control of and valid for the whole origin. This mitigates is under control of and valid for the whole origin. This mitigates
the attack described in Section 9.2. the attack described in Section 9.2.
For the purposes of this document, "reasonable assurances" can be For the purposes of this document, "reasonable assurances" can be
established through use of a TLS-based protocol with the certificate established through use of a TLS-based protocol with the certificate
checks defined in [RFC2818]. Other means of establishing them MUST checks defined in [RFC2818]. Clients MAY impose additional criteria
be documented in an RFC that updates this specification. Clients MAY for establishing reasonable assurances.
impose additional criteria for establishing reasonable assurances.
For example, if the origin's host is "www.example.com" and an For example, if the origin's host is "www.example.com" and an
alternative is offered on "other.example.com" with the "h2" protocol, alternative is offered on "other.example.com" with the "h2" protocol,
and the certificate offered is valid for "www.example.com", the and the certificate offered is valid for "www.example.com", the
client can use the alternative. However, if either is offered with client can use the alternative. However, if either is offered with
the "h2c" protocol, the client cannot use it, because there is no the "h2c" protocol, the client cannot use it, because there is no
mechanism (at the time of the publication of this specification) in mechanism (at the time of the publication of this specification) in
that protocol to establish the relationship between the origin and that protocol to establish the relationship between the origin and
the alternative. the alternative.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 NOT use a TLS-based alternative service unless the
also supports TLS Server Name Indication (SNI). This supports the client supports TLS Server Name Indication (SNI). This supports the
conservation of IP addresses on the alternative service host. conservation of IP addresses on the alternative service host.
Note that the SNI information provided in TLS by the client will be 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 that of the origin, not the alternative (as will the Host HTTP header
field value). field value).
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 alternative services are used by servers, in a predictable way when alternative services are used by servers,
to aid purposes like load balancing. to aid purposes like load balancing.
Therefore, if a client becomes aware of an alternative service, the Therefore, if a client supporting this specification becomes aware of
client SHOULD use that alternative service for all requests to the an alternative service, the client SHOULD use that alternative
associated origin as soon as it is available, provided the service for all requests to the associated origin as soon as it is
alternative service information is fresh (Section 2.2) and the available, provided the alternative service information is fresh
security properties of the alternative service protocol are (Section 2.2) and the security properties of the alternative service
desirable, as compared to the existing connection. A viable protocol are desirable, as compared to the existing connection. A
alternative service is then treated in every way as the origin; this viable alternative service is then treated in every way as the
includes the ability to advertise alternative services. origin; this includes the ability to advertise alternative services.
If a client becomes aware of multiple alternative services, it If a client becomes aware of multiple alternative services, it
chooses the most suitable according to its own criteria, keeping chooses the most suitable according to its own criteria, keeping
security properties in mind. For example, an origin might advertise security properties in mind. For example, an origin might advertise
multiple alternative services to notify clients of support for multiple alternative services to notify clients of support for
multiple versions of HTTP. multiple versions of HTTP.
A client configured to use a proxy for a given request SHOULD NOT A client configured to use a proxy for a given request SHOULD NOT
directly connect to an alternative service for this request, but directly connect to an alternative service for this request, but
instead route it through that proxy. instead route it through that proxy.
skipping to change at page 17, line 20 skipping to change at page 17, line 20
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
masquerade as that origin. This can be done locally (see mitigations 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- in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
the-middle attack). the-middle attack).
This is the reason for the requirement in Section 2.1 that clients This is the reason for the requirement in Section 2.1 that clients
have reasonable assurances that the alternative service is under have reasonable assurances that the alternative service is under
control of and valid for the whole origin; presenting a certificate control of and valid for the whole origin; for example, presenting a
for the origin proves that the alternative service is authorized to certificate for the origin proves that the alternative service is
serve traffic for the origin. authorized to serve traffic for the origin.
Note that this assurance is only as strong as the method used to Note that this assurance is only as strong as the method used to
authenticate the alternative service. In particular, when TLS authenticate the alternative service. In particular, when TLS
authentication is used to do so, there are well-known exploits to authentication is used to do so, there are well-known exploits to
make an attacker's certificate appear as legitimate. make an attacker's certificate appear as 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
skipping to change at page 19, line 4 skipping to change at page 19, line 4
This risk can be mitigated in servers by using the URI scheme This risk can be mitigated in servers by using the URI scheme
explicitly carried by the protocol (such as ":scheme" in HTTP/2 or 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 the "absolute form" of the request target in HTTP/1.1) as an
indication of security context, instead of other connection indication of security context, instead of other connection
properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 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 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 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 either assuming that all requests have an insecure context, or by
refraining from advertising alternative services for insecure refraining from advertising alternative services for insecure schemes
schemes, for example HTTP. (for example, 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>.
 End of changes. 9 change blocks. 
22 lines changed or deleted 21 lines changed or added

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