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