draft-ietf-httpbis-http2-encryption-05.txt   draft-ietf-httpbis-http2-encryption-06.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 2, 2016 Mozilla Expires: December 23, 2016 Mozilla
May 31, 2016 June 21, 2016
Opportunistic Security for HTTP Opportunistic Security for HTTP
draft-ietf-httpbis-http2-encryption-05 draft-ietf-httpbis-http2-encryption-06
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 December 2, 2016. This Internet-Draft will expire on December 23, 2016.
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 23 skipping to change at page 2, line 23
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
3. Server Authentication . . . . . . . . . . . . . . . . . . . . 4 3. Server Authentication . . . . . . . . . . . . . . . . . . . . 4
4. Interaction with "https" URIs . . . . . . . . . . . . . . . . 5 4. Interaction with "https" URIs . . . . . . . . . . . . . . . . 5
5. Requiring Use of TLS . . . . . . . . . . . . . . . . . . . . 5 5. Requiring Use of TLS . . . . . . . . . . . . . . . . . . . . 6
5.1. Opportunistic Commitment . . . . . . . . . . . . . . . . 6 5.1. Opportunistic Commitment . . . . . . . . . . . . . . . . 6
5.2. Client Handling of A Commitment . . . . . . . . . . . . . 6 5.2. Client Handling of A Commitment . . . . . . . . . . . . . 7
5.3. Operational Considerations . . . . . . . . . . . . . . . 7 5.3. Operational Considerations . . . . . . . . . . . . . . . 7
6. The "http-opportunistic" well-known URI . . . . . . . . . . . 7 6. The "http-opportunistic" well-known URI . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Security Indicators . . . . . . . . . . . . . . . . . . . 8 8.1. Security Indicators . . . . . . . . . . . . . . . . . . . 9
8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 8 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 9
8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 9 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 9
8.4. Confusion Regarding Request Scheme . . . . . . . . . . . 9 8.4. Confusion Regarding Request Scheme . . . . . . . . . . . 9
8.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 9 8.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 require acquiring and configuring a valid Serving "https" URIs require acquiring and configuring a valid
certificate, which means that some deployments find supporting TLS certificate, which means that some deployments find supporting TLS
skipping to change at page 4, line 12 skipping to change at page 4, line 12
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
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"
scheme, and therefore clients creating new TLS connections to
alternative services for the purposes of this specification MUST NOT
present them. Established connections with client certificates MAY
be reused, however.
3. Server Authentication 3. Server Authentication
[RFC7838] requires that an alternative service only be used when [RFC7838] requires that an alternative service only be used when
there are "reasonable assurances" that it is under control of and there are "reasonable assurances" that it is under control of and
valid for the whole origin. valid for the whole origin.
As defined in that specification, a client can establish reasonable As defined in that specification, a client can establish reasonable
assurances when using a TLS-based protocol with the certificate assurances when using a TLS-based protocol with the certificate
checks defined in [RFC2818]. checks defined in [RFC2818].
skipping to change at page 5, line 14 skipping to change at page 5, line 18
GET /.well-known/http-opportunistic HTTP/1.1 GET /.well-known/http-opportunistic HTTP/1.1
Host: www.example.com Host: www.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://www.example.com": {
"tls-ports": [443, 8000] "tls-ports": [443, 8000],
"lifetime": 2592000
} }
} }
Note that this mechanism is only defined to establish reasonable Note that this mechanism is only defined to establish reasonable
assurances for the purposes of this specification; it does not apply assurances for the purposes of this specification; it does not apply
to other uses of alternative services unless they explicitly invoke to other uses of alternative services unless they explicitly invoke
it. it.
4. Interaction with "https" URIs 4. Interaction with "https" URIs
skipping to change at page 5, line 40 skipping to change at page 5, line 45
is initially created for "http" URIs without authenticating the is initially created for "http" URIs without authenticating the
server cannot be used for "https" URIs until the server certificate server cannot be used for "https" URIs until the server certificate
is successfully authenticated. Section 3.1 of [RFC2818] describes is successfully authenticated. Section 3.1 of [RFC2818] describes
the basic mechanism, though the authentication considerations in the basic mechanism, though the authentication considerations in
Section 2.1 of [RFC7838] also apply. Section 2.1 of [RFC7838] also apply.
Connections that are established without any means of server Connections that are established without any means of server
authentication (for instance, the purely anonymous TLS cipher suites) authentication (for instance, the purely anonymous TLS cipher suites)
cannot be used for "https" URIs. cannot be used for "https" URIs.
Because of the risk of server confusion about individual requests'
schemes (see Section 8.4), clients MUST NOT mix "https" and "http"
requests on the same connection unless the http-opportunistic
response's origin object Section 6 has a "mixed-scheme" member whose
value is "true".
5. Requiring Use of TLS 5. Requiring Use of TLS
Even when the alternative service is strongly authenticated, Even when the alternative service is strongly authenticated,
opportunistically upgrading cleartext HTTP connections to use TLS is opportunistically upgrading cleartext HTTP connections to use TLS is
subject to active attacks. In particular: subject to active attacks. In particular:
o Because the original HTTP connection is in cleartext, it is o Because the original HTTP connection is in cleartext, it is
vulnerable to man-in-the-middle attacks, and vulnerable to man-in-the-middle attacks, and
o By default, if clients cannot reach the alternative service, they o By default, if clients cannot reach the alternative service, they
skipping to change at page 6, line 28 skipping to change at page 6, line 40
An origin can reduce the risk of attacks on opportunistically secured An origin can reduce the risk of attacks on opportunistically secured
connections by committing to provide a secured, authenticated connections by committing to provide a secured, authenticated
alternative service. This is done by including the optional "tls- alternative service. This is done by including the optional "tls-
commit" member in the origin object of the http-opportunistic well- commit" member in the origin object of the http-opportunistic well-
known response (see Section 6). known response (see Section 6).
This feature is optional due to the requirement for server This feature is optional due to the requirement for server
authentication and the potential risk entailed (see Section 5.3). authentication and the potential risk entailed (see Section 5.3).
The value of the "tls-commit" member is a number ([RFC7159], When the value of the "tls-commit" member is "true" ([RFC7159],
Section 6) indicating the duration of the commitment interval in Section 3), it indicates that the origin makes such a commitment for
seconds. the duration of the origin object lifetime.
{ {
"http://www.example.com": { "http://www.example.com": {
"tls-ports": [443,8080], "tls-ports": [443,8080],
"tls-commit": 3600 "tls-commit": true,
"lifetime": 3600
} }
} }
Including "tls-commit" creates a commitment to provide a secured Including "tls-commit" creates a commitment to provide a secured
alternative service for the advertised period. Clients that receive alternative service for the advertised period. Clients that receive
this commitment can assume that a secured alternative service will be this commitment can assume that a secured alternative service will be
available for the indicated period. Clients might however choose to available for the origin object lifetime. Clients might however
limit this time (see Section 5.3). choose to limit this time (see Section 5.3).
5.2. Client Handling of A Commitment 5.2. Client Handling of A Commitment
The value of the "tls-commit" member MUST be ignored unless the The value of the "tls-commit" member MUST be ignored unless the
alternative service can be strongly authenticated. The same alternative service can be strongly authenticated. The same
authentication requirements that apply to "https://" resources SHOULD authentication requirements that apply to "https://" resources SHOULD
be applied to authenticating the alternative. Minimum authentication be applied to authenticating the alternative. Minimum authentication
requirements for HTTP over TLS are described in Section 2.1 of requirements for HTTP over TLS are described in Section 2.1 of
[RFC7838] and Section 3.1 of [RFC2818]. As noted in [RFC7838], [RFC7838] and Section 3.1 of [RFC2818]. As noted in [RFC7838],
clients can impose other checks in addition to this minimum set. For clients can impose other checks in addition to this minimum set. For
instance, a client might choose to apply key pinning [RFC7469]. instance, a client might choose to apply key pinning [RFC7469].
A client that receives a commitment and that successfully A client that receives a commitment and that successfully
authenticates the alternative service can assume that a secured authenticates the alternative service can assume that a secured
alternative will remain available for the commitment interval. The alternative will remain available for the origin object lifetime.
commitment interval starts when the commitment is received and
authenticated and runs for a number of seconds equal to value of the
"tls-commit" member, less the current age of the http-opportunistic
response (as defined in Section 4.2.3 of [RFC7234]). Note that the
commitment interval MAY exceed the freshness lifetime of the "http-
opportunistic" resource.
A client SHOULD avoid sending requests via cleartext protocols or to A client SHOULD avoid sending requests via cleartext protocols or to
unauthenticated alternative services for the duration of the unauthenticated alternative services for the duration of the origin
commitment interval, except to discover new potential alternatives. object lifetime, except to discover new potential alternatives.
A commitment is not bound to a particular alternative service. A commitment is not bound to a particular alternative service.
Clients are able to use alternative services that they become aware Clients are able to use alternative services that they become aware
of. However, once a valid and authenticated commitment has been of. However, once a valid and authenticated commitment has been
received, clients SHOULD NOT use an unauthenticated alternative received, clients SHOULD NOT use an alternative service without both
service. Where there is an active commitment, clients SHOULD ignore reasonable assurances (see Section 3) and strong authentication.
advertisements for unsecured alternative services. A client MAY send Where there is an active commitment, clients SHOULD ignore
requests to an unauthenticated origin in an attempt to discover advertisements for unsecured alternative services.
potential alternative services, but these requests SHOULD be entirely
generic and avoid including credentials. A client MAY send requests to an unauthenticated origin in an attempt
to discover potential alternative services, but these requests SHOULD
be entirely generic and avoid including credentials.
5.3. Operational Considerations 5.3. Operational Considerations
Errors in configuration of commitments has the potential to render Errors in configuration of commitments has the potential to render
even the unsecured origin inaccessible for the duration of a even the unsecured origin inaccessible for the duration of a
commitment. Initial deployments are encouraged to use short duration commitment. Initial deployments are encouraged to use short duration
commitments so that errors can be detected without causing the origin commitments so that errors can be detected without causing the origin
to become inaccessible to clients for extended periods. to become inaccessible to clients for extended periods.
To avoid situations where a commitment causes errors, clients MAY To avoid situations where a commitment causes errors, clients MAY
skipping to change at page 8, line 12 skipping to change at page 8, line 21
[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. an object as the root, and
o The root object contains a member whose name is a case-insensitive o The root object contains a member whose name is a case-insensitive
character-for-character match for the origin in question, character-for-character match for the origin in question,
serialised into Unicode as per Section 6.1 of [RFC6454], and whose serialised into Unicode as per Section 6.1 of [RFC6454], and whose
value is an object (hereafter, the "origin object"). 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
per [RFC7234], Section 4.2.3).
Note that origin object lifetime might differ from the freshness
lifetime of the response.
7. IANA Considerations 7. 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 6 of [this specification] o Specification Document(s): Section 6 of [this specification]
skipping to change at page 11, line 42 skipping to change at page 12, line 12
Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen
Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam
Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard
Barnes for their feedback and suggestions. Barnes for their feedback and suggestions.
Authors' Addresses Authors' Addresses
Mark Nottingham Mark Nottingham
Email: mnot@mnot.net Email: mnot@mnot.net
URI: http://www.mnot.net/ URI: https://www.mnot.net/
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
 End of changes. 23 change blocks. 
39 lines changed or deleted 57 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/