< draft-ietf-httpbis-http2-encryption-08.txt		draft-ietf-httpbis-http2-encryption-09.txt >
	HTTP Working Group M. Nottingham		HTTP Working Group M. Nottingham
	Internet-Draft		Internet-Draft
	Intended status: Experimental M. Thomson		Intended status: Experimental M. Thomson
	Expires: May 4, 2017 Mozilla		Expires: June 24, 2017 Mozilla
	October 31, 2016		December 21, 2016
	Opportunistic Security for HTTP		Opportunistic Security for HTTP
	draft-ietf-httpbis-http2-encryption-08		draft-ietf-httpbis-http2-encryption-09
	Abstract		Abstract
	This document describes how "http" URIs can be accessed using		This document describes how "http" URIs can be accessed using
	Transport Layer Security (TLS) to mitigate pervasive monitoring		Transport Layer Security (TLS) to mitigate pervasive monitoring
	attacks.		attacks.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 May 4, 2017.		This Internet-Draft will expire on June 24, 2017.
	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 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 3		1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 3
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3		2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3
	2.1. Alternative Server Opt-In . . . . . . . . . . . . . . . . 4		2.1. Alternative Server Opt-In . . . . . . . . . . . . . . . . 4
	2.2. Interaction with "https" URIs . . . . . . . . . . . . . . 4		2.2. Interaction with "https" URIs . . . . . . . . . . . . . . 5
	2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5		2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4.1. Security Indicators . . . . . . . . . . . . . . . . . . . 6		4.1. Security Indicators . . . . . . . . . . . . . . . . . . . 6
	4.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 6		4.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 6
	4.3. Privacy Considerations . . . . . . . . . . . . . . . . . 6		4.3. Privacy Considerations . . . . . . . . . . . . . . . . . 6
	4.4. Confusion Regarding Request Scheme . . . . . . . . . . . 6		4.4. Confusion Regarding Request Scheme . . . . . . . . . . . 6
	4.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 7		4.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 7
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Normative References . . . . . . . . . . . . . . . . . . 7		5.1. Normative References . . . . . . . . . . . . . . . . . . 7
	5.2. Informative References . . . . . . . . . . . . . . . . . 8		5.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document describes a use of HTTP Alternative Services [RFC7838]		This document describes a use of HTTP Alternative Services [RFC7838]
	to decouple the URI scheme from the use and configuration of		to decouple the URI scheme from the use and configuration of
	underlying encryption, allowing a "http" URI [RFC7230] to be accessed		underlying encryption, allowing a "http" URI [RFC7230] to be accessed
	using Transport Layer Security (TLS) [RFC5246] opportunistically.		using Transport Layer Security (TLS) [RFC5246] opportunistically.
	Serving "https" URIs requires avoiding Mixed Content		Serving "https" URIs requires avoiding Mixed Content
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Using HTTP URIs over TLS		2. Using HTTP URIs over TLS
	An origin server that supports the resolution of "http" URIs can		An origin server that supports the resolution of "http" URIs can
	indicate support for this specification by providing an alternative		indicate support for this specification by providing an alternative
	service advertisement [RFC7838] for a protocol identifier that uses		service advertisement [RFC7838] for a protocol identifier that uses
	TLS, such as "h2" [RFC7540], or "http/1.1" [RFC7301]. Note that		TLS, such as "h2" [RFC7540]. Such a protocol MUST include an
	HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of		explicit indication of the scheme of the resource. This excludes
			HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute
			form of a URI in requests to origin servers (see Section 5.3.1 of
	[RFC7230]).		[RFC7230]).
	A client that receives such an advertisement MAY make future requests		A client that receives such an advertisement MAY make future requests
	intended for the associated origin ([RFC6454]) to the identified		intended for the associated origin [RFC6454] to the identified
	service (as specified by [RFC7838]), provided that the alternative		service (as specified by [RFC7838]), provided that the alternative
	service opts in as described in Section 2.1.		service opts in as described in Section 2.1.
	A client that places the importance of protection against passive		A client that places the importance of protection against passive
	attacks over performance might choose to withhold requests until an		attacks over performance might choose to withhold requests until an
	encrypted connection is available. However, if such a connection		encrypted connection is available. However, if such a connection
	cannot be successfully established, the client can resume its use of		cannot be successfully established, the client can resume its use of
	the cleartext connection.		the cleartext connection.
	A client can also explicitly probe for an alternative service		A client can also explicitly probe for an alternative service
	skipping to change at page 4, line 36 ¶		skipping to change at page 5, line 5 ¶
	"reasonable assurances" for the purposes of {RFC7838}}) - and they		"reasonable assurances" for the purposes of {RFC7838}}) - and they
	have obtained a valid http-opportunistic response for an origin (as		have obtained a valid http-opportunistic response for an origin (as
	per Section 2.3).		per Section 2.3).
	For example, assuming the following request is made over a TLS		For example, assuming the following request is made over a TLS
	connection that is successfully authenticated for those origins, the		connection that is successfully authenticated for those origins, the
	following request/response pair would allow requests for the origins		following request/response pair would allow requests for the origins
	"http://www.example.com" or "http://example.com" to be sent using a		"http://www.example.com" or "http://example.com" to be sent using a
	secured connection:		secured connection:
	GET http://example.com/.well-known/http-opportunistic HTTP/1.1		HEADERS
	Host: example.com		+ END_STREAM
			+ END_HEADERS
	HTTP/1.1 200 OK		:method = GET
	Content-Type: application/json		:scheme = http
	Connection: close		:path = /.well-known/http-opportunistic
			host: example.com
			HEADERS
			:status = 200
			content-type = application/json
			DATA
			+ END_STREAM
	[ "http://www.example.com", "http://example.com" ]		[ "http://www.example.com", "http://example.com" ]
	2.2. Interaction with "https" URIs		2.2. Interaction with "https" URIs
	When using alternative services, requests for resources identified by		Clients MUST NOT send "http" requests and "https" requests on the
	both "http" and "https" URIs might use the same connection, because		same connection. Similarly, clients MUST NOT send "http" requests
	HTTP/2 permits requests for multiple origins on the same connection.		for multiple origins on the same connection.
	Because of the potential for server confusion about the scheme of
	requests (see Section 4.4), clients MUST NOT send "http" requests on
	a connection prior to successfully retrieving a valid http-
	opportunistic resource that contains the origin (see Section 2.3).
	The primary purpose of this check is to provide a client with some
	assurance that a server understands this specification and has taken
	steps to avoid being confused about request scheme.
	2.3. The "http-opportunistic" well-known URI		2.3. The "http-opportunistic" well-known URI
	This specification defines the "http-opportunistic" well-known URI		This specification defines the "http-opportunistic" well-known URI
	[RFC5785]. A client is said to have a valid http-opportunistic		[RFC5785]. A client is said to have a valid http-opportunistic
	response for a given origin when:		response for a given origin when:
	o The client has obtained a 200 (OK) response for the well-known URI		o The client has obtained a 200 (OK) response for the well-known URI
	from the origin, and it is fresh [RFC7234] (potentially through		from the origin, and it is fresh [RFC7234] (potentially through
	revalidation [RFC7232]), and		revalidation [RFC7232]), and
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 48 ¶
	o That response's payload, when parsed as JSON [RFC7159], contains		o That response's payload, when parsed as JSON [RFC7159], contains
	an array as the root, and		an array as the root, and
	o The array contains a string that is a case-insensitive character-		o The array contains a string that is a case-insensitive character-
	for-character match for the origin in question, serialised into		for-character match for the origin in question, serialised into
	Unicode as per Section 6.1 of [RFC6454].		Unicode as per Section 6.1 of [RFC6454].
	A client MAY treat an "http-opportunistic" resource as invalid if the		A client MAY treat an "http-opportunistic" resource as invalid if the
	contains values that are not strings.		contains values that are not strings.
			This document does not define semantics for "http-opportunistic"
			resources on an "https" origin, nor does it define semantics if the
			resource includes "https" origins.
	3. IANA Considerations		3. IANA Considerations
	This specification registers a Well-Known URI [RFC5785]:		This specification registers a Well-Known URI [RFC5785]:
	o URI Suffix: http-opportunistic		o URI Suffix: http-opportunistic
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 2.3 of [this specification]		o Specification Document(s): Section 2.3 of [this specification]
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 50 ¶
	ability of servers to track clients; therefore clients MUST clear		ability of servers to track clients; therefore clients MUST clear
	cached alternative service information when clearing other origin-		cached alternative service information when clearing other origin-
	based state (i.e., cookies).		based state (i.e., cookies).
	4.4. Confusion Regarding Request Scheme		4.4. Confusion Regarding Request Scheme
	HTTP implementations and applications sometimes use ambient signals		HTTP implementations and applications sometimes use ambient signals
	to determine if a request is for an "https" resource; for example,		to determine if a request is for an "https" resource; for example,
	they might look for TLS on the stack, or a server port number of 443.		they might look for TLS on the stack, or a server port number of 443.
	This might be due to limitations in the protocol (the most common		This might be due to expected limitations in the protocol (the most
	HTTP/1.1 request form does not carry an explicit indication of the		common HTTP/1.1 request form does not carry an explicit indication of
	URI scheme), or it may be because how the server and application are		the URI scheme and the resource might have been developed assuming
			HTTP/1.1), or it may be because how the server and application are
	implemented (often, they are two separate entities, with a variety of		implemented (often, they are two separate entities, with a variety of
	possible interfaces between them).		possible interfaces between them).
	Any security decisions based upon this information could be misled by		Any security decisions based upon this information could be misled by
	the deployment of this specification, because it violates the		the deployment of this specification, because it violates the
	assumption that the use of TLS (or port 443) means that the client is		assumption that the use of TLS (or port 443) means that the client is
	accessing a HTTPS URI, and operating in the security context implied		accessing a HTTPS URI, and operating in the security context implied
	by HTTPS.		by HTTPS.
	Therefore, servers need to carefully examine the use of such signals		Therefore, servers need to carefully examine the use of such signals
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 43 ¶
	[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP		[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
	Alternative Services", RFC 7838, DOI 10.17487/RFC7838,		Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
	April 2016, <http://www.rfc-editor.org/info/rfc7838>.		April 2016, <http://www.rfc-editor.org/info/rfc7838>.
	5.2. Informative References		5.2. Informative References
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://www.rfc-editor.org/info/rfc7258>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <http://www.rfc-editor.org/info/rfc7301>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <http://www.rfc-editor.org/info/rfc7435>.		December 2014, <http://www.rfc-editor.org/info/rfc7435>.
	[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, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <http://www.rfc-editor.org/info/rfc7469>.		2015, <http://www.rfc-editor.org/info/rfc7469>.
	[W3C.CR-mixed-content-20160802]		[W3C.CR-mixed-content-20160802]
	West, M., "Mixed Content", World Wide Web Consortium CR		West, M., "Mixed Content", World Wide Web Consortium CR
End of changes. 14 change blocks.
	36 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/