< draft-ietf-httpbis-http2-encryption-02.txt		draft-ietf-httpbis-http2-encryption-03.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: December 17, 2015 Mozilla		Expires: June 19, 2016 Mozilla
	June 15, 2015		December 17, 2015
	Opportunistic Security for HTTP		Opportunistic Security for HTTP
	draft-ietf-httpbis-http2-encryption-02		draft-ietf-httpbis-http2-encryption-03
	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.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 December 17, 2015.		This Internet-Draft will expire on June 19, 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 17 ¶		skipping to change at page 3, line 17 ¶
	The immediate goal is to make the use of HTTP more robust in the face		The immediate goal is to make the use of HTTP more robust in the face
	of pervasive passive monitoring [RFC7258].		of pervasive passive monitoring [RFC7258].
	A secondary goal is to limit the potential for active attacks. It is		A secondary goal is to limit the potential for active attacks. It is
	not intended to offer the same level of protection as afforded to		not intended to offer the same level of protection as afforded to
	"https" URIs, but instead to increase the likelihood that an active		"https" URIs, but instead to increase the likelihood that an active
	attack can be detected.		attack can be detected.
	A final (but significant) goal is to provide for ease of		A final (but significant) goal is to provide for ease of
	implementation, deployment and operation. This mechanism is expected		implementation, deployment and operation. This mechanism is expected
	to have a minimal impact upon performance, and a trivial		to have a minimal impact upon performance, and require a trivial
	administrative effort to configure.		administrative effort to configure.
	1.2. Notational Conventions		1.2. Notational Conventions
	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
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 23 ¶
	6.4. Confusion Regarding Request Scheme		6.4. Confusion Regarding Request Scheme
	Many existing HTTP/1.1 implementations use the presence or absence of		Many existing HTTP/1.1 implementations use the presence or absence of
	TLS in the stack to determine whether requests are for "http" or		TLS in the stack to determine whether requests are for "http" or
	"https" resources. This is necessary in many cases because the most		"https" resources. This is necessary in many cases because the most
	common form of an HTTP/1.1 request does not carry an explicit		common form of an HTTP/1.1 request does not carry an explicit
	indication of the URI scheme.		indication of the URI scheme.
	HTTP/1.1 MUST NOT be used for opportunistically secured requests.		HTTP/1.1 MUST NOT be used for opportunistically secured requests.
			Some HTTP/1.1 implementations use ambient signals to determine if a
			request is for an "https" resource. For example, implementations
			might look for TLS on the stack or a port number of 443. An
			implementation that supports opportunistically secured requests
			SHOULD suppress these signals if there is any potential for
			confusion.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-httpbis-alt-svc]		[I-D.ietf-httpbis-alt-svc]
	mnot, m., McManus, P., and J. Reschke, "HTTP Alternative		mnot, m., McManus, P., and J. Reschke, "HTTP Alternative
	Services", draft-ietf-httpbis-alt-svc-07 (work in		Services", draft-ietf-httpbis-alt-svc-09 (work in
	progress), May 2015.		progress), November 2015.
	[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,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[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,
	RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<http://www.rfc-editor.org/info/rfc6454>.		<http://www.rfc-editor.org/info/rfc6454>.
	[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10		Protocol (HTTP/1.1): Message Syntax and Routing",
	.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<http://www.rfc-editor.org/info/rfc7234>.		<http://www.rfc-editor.org/info/rfc7234>.
	[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>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<http://www.rfc-editor.org/info/rfc7540>.		<http://www.rfc-editor.org/info/rfc7540>.
	7.2. Informative References		7.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>.
	[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,
End of changes. 13 change blocks.
	24 lines changed or deleted		31 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/