< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/