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