draft-ietf-httpbis-alt-svc-11.txt   draft-ietf-httpbis-alt-svc-12.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: August 6, 2016 Mozilla Expires: August 12, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
February 3, 2016 February 9, 2016
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-11 draft-ietf-httpbis-alt-svc-12
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 August 6, 2016. This Internet-Draft will expire on August 12, 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 3, line 30 skipping to change at page 3, line 30
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 . . . . . . . . . . . . . 16 8. Internationalization Considerations . . . . . . . . . . . . . 16
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 . . . . . . . 18 9.4. Tracking Clients Using Alternative Services . . . . . . . 17
9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 20
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20
A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 21 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20
A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 22 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21
A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 21
A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23
A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 23
A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24 A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24
A.13. Since draft-ietf-httpbis-alt-svc-11 . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
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://") URIs are used location. In other words, "http://" (and "https://") URIs 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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
There are many ways that a client could discover the alternative There are many ways that a client could discover the alternative
service(s) associated with an origin. This document describes two service(s) associated with an origin. This document describes two
such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the
"ALTSVC" HTTP/2 frame type (Section 4). "ALTSVC" HTTP/2 frame type (Section 4).
The remainder of this section describes requirements that are common The remainder of this section describes requirements that are common
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 NOT use alternative services with a host that is Clients MUST have reasonable assurances that the alternative service
different from the origin's without strong server authentication; is under control of and valid for the whole origin. This mitigates
this mitigates the attack described in Section 9.2. One way to the attack described in Section 9.2. One way to achieve this is for
achieve this is for the alternative to use TLS with a certificate the alternative to use TLS with a certificate that is valid for the
that is valid for that origin. origin.
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 "other.example.com" is client can use the alternative. However, if "other.example.com" is
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 the relationship
authentication. between the origin and the alternative.
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 can 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.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
configuration change. configuration change.
Syntax: Syntax:
persist = "1" persist = "1"
For example: For example:
Alt-Svc: h2=":443"; ma=2592000; persist=1 Alt-Svc: h2=":443"; ma=2592000; persist=1
This specification only a defines a single value for "persist". This specification only defines a single value for "persist".
Clients MUST ignore "persist" parameters with values other than "1". Clients MUST ignore "persist" parameters with values other than "1".
See Section 2.2 for general requirements on caching alternative See Section 2.2 for general requirements on caching alternative
services. services.
4. The ALTSVC HTTP/2 Frame 4. The ALTSVC HTTP/2 Frame
The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
availability of an alternative service to an HTTP/2 client. availability of an alternative service to an HTTP/2 client.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
able to hijack an origin. On certain servers, it is normal for users 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, to be able to control some personal pages available on a shared port,
and also to accept to requests on less-privileged ports. and also to accept to requests on less-privileged ports.
For example, an attacker that can add HTTP response header fields to For example, an attacker that can add HTTP response header fields to
some pages can redirect traffic for an entire origin to a different 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 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 under the attacker's control, they can thus masquerade as the HTTP
server. server.
On servers, this risk can be reduced by restricting the ability to This risk is mitigated by the requirements in Section 2.1.
advertise alternative services, and restricting who can open a port
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 On servers, this risk can also be reduced by restricting the ability
advertisement which does not meet its implementation-specific to advertise alternative services, and restricting who can open a
security requirements. Servers can increase the likelihood of port for listening on that host.
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
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 any This is the reason for the requirement in Section 2.1 that clients
alternative service with a host different from the origin's be have reasonable assurances that the alternative service is under
strongly authenticated with the origin's identity; i.e., presenting a control of and valid for the whole origin; i.e., presenting a
certificate for the origin proves that the alternative service is certificate for the origin proves that the alternative service is
authorized to serve traffic for the origin. authorized to serve traffic for the origin.
However, this authorization 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, there are well- authenticate the alternative service. In particular, when TLS
known exploits to make an attacker's certificate appear as authentication is used to do so, there are well-known exploits to
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
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. Implementations MUST perform any certificate-pinning validation (e.g.
[RFC7469]) on alternative services just as they would on direct [RFC7469]) on alternative services just as they would on direct
skipping to change at page 20, line 28 skipping to change at page 20, line 21
[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 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
April 2015, <http://www.rfc-editor.org/info/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
skipping to change at page 24, line 28 skipping to change at page 24, line 13
<https://github.com/httpwg/http-extensions/issues/126>). <https://github.com/httpwg/http-extensions/issues/126>).
A.12. Since draft-ietf-httpbis-alt-svc-10 A.12. Since draft-ietf-httpbis-alt-svc-10
Editorial improvements Editorial improvements
(<https://github.com/httpwg/http-extensions/issues/130>). (<https://github.com/httpwg/http-extensions/issues/130>).
Use RFC 7405 ABNF extension Use RFC 7405 ABNF extension
(<https://github.com/httpwg/http-extensions/issues/131>). (<https://github.com/httpwg/http-extensions/issues/131>).
A.13. Since draft-ietf-httpbis-alt-svc-11
Security considerations wrt system ports
(<https://github.com/httpwg/http-extensions/issues/139>).
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, Lucas Pardue, Martin Thomson, Matthew Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew
Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury,
Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and
suggestions. 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.
 End of changes. 19 change blocks. 
44 lines changed or deleted 36 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/