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