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