< draft-ietf-httpbis-http2-encryption-07.txt		draft-ietf-httpbis-http2-encryption-08.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: April 7, 2017 Mozilla		Expires: May 4, 2017 Mozilla
	October 4, 2016		October 31, 2016
	Opportunistic Security for HTTP		Opportunistic Security for HTTP
	draft-ietf-httpbis-http2-encryption-07		draft-ietf-httpbis-http2-encryption-08
	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 April 7, 2017.		This Internet-Draft will expire on May 4, 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 . . . . . . . . . . . . . . 5		2.2. Interaction with "https" URIs . . . . . . . . . . . . . . 4
	2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5		2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . 7		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 . . . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
	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].		TLS, such as "h2" [RFC7540], or "http/1.1" [RFC7301]. Note that
			HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of
			[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
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 11 ¶
	A client can also explicitly probe for an alternative service		A client can also explicitly probe for an alternative service
	advertisement by sending a request that bears little or no sensitive		advertisement by sending a request that bears little or no sensitive
	information, such as one with the OPTIONS method. Likewise, clients		information, such as one with the OPTIONS method. Likewise, clients
	with existing alternative services information could make such a		with existing alternative services information could make such a
	request before they expire, in order minimize the delays that might		request before they expire, in order minimize the delays that might
	be incurred.		be incurred.
	Client certificates are not meaningful for URLs with the "http"		Client certificates are not meaningful for URLs with the "http"
	scheme, and therefore clients creating new TLS connections to		scheme, and therefore clients creating new TLS connections to
	alternative services for the purposes of this specification MUST NOT		alternative services for the purposes of this specification MUST NOT
	present them. Established connections with client certificates MAY		present them. Connections that use client certificates for other
	be reused, however.		reasons MAY be reused, though client certificates MUST NOT affect the
			responses to requests for "http" resources.
	2.1. Alternative Server Opt-In		2.1. Alternative Server Opt-In
	It is possible that the server might become confused about whether		It is possible that the server might become confused about whether
	requests' URLs have a "http" or "https" scheme, for various reasons;		requests' URLs have a "http" or "https" scheme, for various reasons;
	see Section 4.4. To ensure that the alternative service has opted		see Section 4.4. To ensure that the alternative service has opted
	into serving "http" URLs over TLS, clients are required to perform		into serving "http" URLs over TLS, clients are required to perform
	additional checks before directing "http" requests to it.		additional checks before directing "http" requests to it.
	Clients MUST NOT send "http" requests over a connection with the "h2"		Clients MUST NOT send "http" requests over a secured connection,
	protocol identifier, unless they have obtained a valid http-		unless the chosen alternative service presents a certificate that is
	opportunistic response for an origin (as per Section 2.3), and:		valid for the origin - as per [RFC2818] (this also establishes
			"reasonable assurances" for the purposes of {RFC7838}}) - and they
	o The chosen alternative service presents a certificate that is		have obtained a valid http-opportunistic response for an origin (as
	valid for the origin, as per [RFC2818] (this also establishes		per Section 2.3).
	"reasonable assurances" for the purposes of {RFC7838}}), and
	o The origin object of the http-opportunistic response has a `tls-
	ports' member, whose value is an array of numbers, one of which
	matches the port of the alternative service in question, and
	o The chosen alternative service returns the same representation as
	the origin did for the http-opportunistic resource.
	For example, this request/response pair would allow reqeusts for the		For example, assuming the following request is made over a TLS
	origin "http://www.example.com" to be sent to an alternative service		connection that is successfully authenticated for those origins, the
	on port 443 or 8000 of the host "www.example.com":		following request/response pair would allow requests for the origins
			"http://www.example.com" or "http://example.com" to be sent using a
			secured connection:
	GET /.well-known/http-opportunistic HTTP/1.1		GET http://example.com/.well-known/http-opportunistic HTTP/1.1
	Host: www.example.com		Host: example.com
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Connection: close		Connection: close
	{		[ "http://www.example.com", "http://example.com" ]
	"http://www.example.com": {
	"tls-ports": [443, 8000],
	"lifetime": 2592000
	}
	}
	2.2. Interaction with "https" URIs		2.2. Interaction with "https" URIs
	When using alternative services, requests for resources identified by		When using alternative services, requests for resources identified by
	both "http" and "https" URIs might use the same connection, because		both "http" and "https" URIs might use the same connection, because
	HTTP/2 permits requests for multiple origins on the same connection.		HTTP/2 permits requests for multiple origins on the same connection.
	Because of the risk of server confusion about individual requests'		Because of the potential for server confusion about the scheme of
	schemes (see Section 4.4), clients MUST NOT send "http" requests on a		requests (see Section 4.4), clients MUST NOT send "http" requests on
	connection that has previously been used for "https" requests, unless		a connection prior to successfully retrieving a valid http-
	the http-opportunistic origin object Section 2.3 fetched over that		opportunistic resource that contains the origin (see Section 2.3).
	connection has a "mixed-scheme" member whose value is "true".		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
	o That response has the media type "application/json", and		o That response has the media type "application/json", and
	o That response's payload, when parsed as JSON [RFC7159], contains		o That response's payload, when parsed as JSON [RFC7159], contains
	an object as the root, and		an array as the root, and
	o The root object contains a member whose name is a case-insensitive
	character-for-character match for the origin in question,
	serialised into Unicode as per Section 6.1 of [RFC6454], and whose
	value is an object (hereafter, the "origin object"),
	o The origin object has a "lifetime" member, whose value is a number
	indicating the number of seconds which the origin object is valid
	for (hereafter, the "origin object lifetime"), and
	o The origin object lifetime is greater than the "current_age" (as		o The array contains a string that is a case-insensitive character-
	per [RFC7234], Section 4.2.3).		for-character match for the origin in question, serialised into
			Unicode as per Section 6.1 of [RFC6454].
	Note that origin object lifetime might differ from the freshness		A client MAY treat an "http-opportunistic" resource as invalid if the
	lifetime of the response.		contains values that are not strings.
	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 8, line 48 ¶		skipping to change at page 8, line 30 ¶
	[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. 18 change blocks.
	56 lines changed or deleted		47 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/