< draft-nottingham-http2-encryption-02.txt   draft-nottingham-http2-encryption-03.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft December 11, 2013 Internet-Draft
Intended status: Standards Track Intended status: Standards Track M. Thomson
Expires: June 14, 2014 Expires: November 21, 2014 Mozilla
May 20, 2014
Opportunistic Encryption for HTTP URIs Opportunistic Encryption for HTTP URIs
draft-nottingham-http2-encryption-02 draft-nottingham-http2-encryption-03
Abstract Abstract
This document proposes two changes to HTTP/2.0; first, it suggests This describes how "http" URIs can be accessed using Transport Layer
using ALPN Protocol Identifies to identify the specific stack of Security (TLS) to mitigate pervasive monitoring attacks.
protocols in use, including TLS, and second, it proposes a way to
opportunistically encrypt HTTP/2.0 using TLS for HTTP URIs.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 14, 2014. This Internet-Draft will expire on November 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 2
1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Proposal: Indicating Security Properties in Protocol 2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Server Authentication . . . . . . . . . . . . . . . . . . . . 3
2.1. Proposal: The "h2r" Protocol . . . . . . . . . . . . . . . 4 4. Interaction with "https" URIs . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Requiring Use of TLS . . . . . . . . . . . . . . . . . . . . 4
3.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . . 5 5.1. The HTTP-TLS Header Field . . . . . . . . . . . . . . . . 5
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Operational Considerations . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . . 6 6.1. Security Indicators . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 6.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 7
Appendix B. Recent History and Background . . . . . . . . . . . . 7 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 7
Appendix C. Frequently Asked Questions . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
C.1. Will this make encryption mandatory in HTTP/2.0? . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
C.2. No certificate checks? Really? . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 8
C.3. Why do this if a downgrade attack is so easy? . . . . . . . 9 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
C.4. Why Have separate relaxed protocol identifiers? . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In discussion at IETF87, it was proposed that the current means of This document describes a use of HTTP Alternative Services
bootstrapping encryption in HTTP [I-D.ietf-httpbis-p1-messaging] - [I-D.ietf-httpbis-alt-svc] to decouple the URI scheme from the use
using the "HTTPS" URI scheme - unintentionally gives the server and configuration of underlying encryption, allowing a "http" URI to
disproportionate power in determining whether encryption (through use be accessed using TLS [RFC5246] opportunistically.
of TLS [RFC6246]) is used.
This document proposes using the new "alternate services" layer Currently, "https" URIs requires acquiring and configuring a valid
described in [I-D.nottingham-httpbis-alt-svc] to decouple the URI certificate, which means that some deployments find supporting TLS
scheme from the use and configuration of underlying encryption, difficult. Therefore, this document describes a usage model whereby
allowing a "http://" URI to be upgraded to use TLS opportunistically. sites can serve "http" URIs over TLS without being required to
support strong server authentication.
Additionally, because using TLS requires acquiring and configuring a A mechanism for limiting the potential for active attacks is
valid certificate, some deployments may find supporting it difficult. described in Section 5. This provides clients with additional
Therefore, this document also proposes a "relaxed" profile of protection against them for a period after successfully connecting to
HTTP/2.0 over TLS that does not require strong server authentication, a server using TLS. This does not offer the same level of protection
specifically for use with "http://" URIs. as afforded to "https" URIs, but increases the likelihood that an
active attack be detected.
1.1. Goals and Non-Goals 1.1. Goals and Non-Goals
The immediate goal is to make HTTP URIs more robust in the face of The immediate goal is to make the use of HTTP more robust in the face
passive monitoring. of pervasive passive monitoring [RFC7258].
Such passive attacks are often opportunistic; they rely on sensitive
information being available in the clear. Furthermore, they are
often broad, where all available data is collected en masse, being
analyzed separately for relevant information.
It is not a goal of this document to address active or targeted A secondary goal is to limit the potential for active attacks. It is
attacks, although future solutions may be complementary. not intended to offer the same level of protection as afforded to
"https" URIs, but instead to increase the likelihood that an active
attack can be detected.
Other goals include ease of implementation and deployment, with A final (but significant) goal is to provide for ease of
minimal impact upon performance (in keeping with the goals of implementation, deployment and operation. This mechanism should have
HTTP/2.0). a minimal impact upon performance, and should not require extensive
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. Proposal: Indicating Security Properties in Protocol Identifiers 2. Using HTTP URIs over TLS
In past discussions, there has been general agreement to reusing the
ALPN protocol identifier [I-D.ietf-tls-applayerprotoneg] for all
negotiation mechanisms in HTTP/2.0, not just TLS.
This document proposes putting additional information into them to
identify the use of encryption as well as configuration of that
encryption, independent of the URI scheme in use.
Thus, we won't have just one protocol identifier for HTTP/2.0, but
two; one with and one without the use of TLS. As such, the following
identifiers are recommended if this approach is adopted:
o h1 - http/1.x over TCP
o h1t - http/1.x over TLS over TCP (as per [RFC2818])
o h2 - http/2.x over TCP
o h2t - http/2.x over TLS over TCP (as per [RFC2818])
o h2r - http/2.x over TLS over TCP (see Section 2.1)
Draft implementations could be indicated with a suffix; e.g., h2t-
draft10.
Most of these are already latently defined by HTTP/2.0, with the
exception being h2r, defined below. Note that the focus of this
proposal is on the semantics of the identifiers; an exact syntax for
them is not part of it.
By indicating the use of TLS in the protocol identifier allows a
client and server to negotiate the use of TLS for "http://" URIs; if
the server offers h2t, the client can select that protocol, start TLS
and use it.
Note that, as discussed in Section 3.1, there may be situations
(e.g,. ALPN) where advertising some of these profiles are
inapplicable or inadvisable. For example, in an ALPN negotiation for
a "https://" URI, it is only sensible to offer h1t and h2t.
If adopted, this proposal would be effected by adjusting the text in
Section 3 of [I-D.ietf-httpbis-http2] ("Starting HTTP/2.0") along the
lines described above. Note that the specific protocol identifiers
above are suggestions only.
2.1. Proposal: The "h2r" Protocol
If the proposal above is adopted, a separate proposal is to define a
separate protocol identifier for "relaxed" TLS operation.
Servers that support the "h2r" protocol indicate that they support An origin server that supports the resolution of HTTP URIs can
TLS for access to URIs with the "http" URI scheme using HTTP/2.0 or indicate support for this specification by providing an alternative
greater. service advertisement [I-D.ietf-httpbis-alt-svc] for a protocol
identifier that uses TLS, such as "h2" [I-D.ietf-httpbis-http2].
Servers MAY advertise the "h2r" profile for resources with a "http" A client that receives such an advertisement MAY direct future
origin scheme; they MUST NOT advertise it for resources with a requests for the associated origin to the identified service (as
"https" origin. specified by [I-D.ietf-httpbis-alt-svc]).
When a client connects to an "h2r" alternate service, it MUST use A client that places the importance of passive protections over
TLS1.1 or greater, and MUST use HTTP/2.x. HTTP/2.0 SHOULD be used as performance might choose to withold requests until an encrypted
soon as TLS negotiation is completed; i.e., the "Upgrade dance" connection is available. However, if such a connection cannot be
SHOULD NOT be performed. successfully established, the client MAY resume its use of the
cleartext connection.
When connecting to an "h2r" service, the algorithm for authenticating A client can also explicitly probe for an alternative service
the server described in [RFC2818] Section 3.1 changes; the client advertisement by sending a request that bears little or no sensitive
does not necessarily validate its certificate for expiry, hostname information, such as one with the OPTIONS method. Clients with
match or relationship to a known certificate authority (as it would expired alternative services information could make a similar request
with "normal" HTTPS). in parallel to an attempt to contact an alternative service, to
minimize the delays that might be incurred by failing to contact the
alternative service.
However, the client MAY perform additional checks on the certificate 3. Server Authentication
and make a decision as to its validity before using the server.
Definition of such additional checks are out of scope for this
specification.
Upon initial adoption of this proposal, it is expected that no such There are no existing expectations with respect to cryptographically
additional checks will be performed. Therefore, the client MUST NOT strong server authentication when it comes to resolving HTTP URIs.
use the "h2r" profile to connect to alternate services whose host Establishing it, as described in [RFC2818], creates a number of
does not match that of the origin (as per operational challenges. For these reasons, server authentication is
[I-D.nottingham-httpbis-alt-svc]), unless additional checks are not mandatory for HTTP URIs when using the mechanism described in
performed. this specification.
Servers SHOULD use the same certificate consistently over time, to When connecting to an alternative service for an "http" URI, clients
aid future extensions for building trust and adding other services. are required to perform the server authentication procedure described
in Section 3.1 of [RFC2818]. The server certificate, if one is
proffered by the alternative service, is not necessarily checked for
validity, expiration, issuance by a trusted certificate authority or
matched against the name in the URI. Therefore, the alternative
service MAY provide any certificate, or even select TLS cipher suites
that do not include authentication.
[TODO: define "same"; likely not the same actual certificate. ] A client MAY perform additional checks on the certificate that it is
offered (if the server does not select an unauthenticated TLS cipher
suite). For instance, a client could examine the certificate to see
if it has changed over time.
When the h2r protocol is in use, User Agents MUST NOT indicate the In order to retain the authority properties of "http" URIs, and as
connection has the same level of security as https:// (e.g. using a stipulated by [I-D.ietf-httpbis-alt-svc], clients MUST NOT use
"lock device"). alternative services that identify a host other than that of the
origin, unless the alternative service indication itself is strongly
authenticated. This is not currently possible for "http" URIs on
cleartext transports.
If this proposal is adopted, the "h2r" protocol could be defined in 4. Interaction with "https" URIs
[I-D.ietf-httpbis-http2] (most likely, Section 3), or in a separate
document.
3. Security Considerations An alternative service that is discovered to support "http" URIs
might concurrently support "https" URIs, because HTTP/2 permits the
sending of requests for multiple origins (see [RFC6454]) on the one
connection. Therefore, when using alternative services, both HTTP
and HTTPS URIs might be sent on the same connection.
3.1. Downgrade Attacks "https" URIs rely on server authentication. Therefore, if a
connection is initially created without authenticating the server,
requests for "https" resources cannot be sent over that connection
until the server certificate is successfully authenticated.
Section 3.1 of [RFC2818] describes the basic mechanism, though the
authentication considerations in [I-D.ietf-httpbis-alt-svc] could
also apply.
A downgrade attack against the negotiation for TLS is possible, Connections that are established without any means of server
depending upon the properties of the negotiation mechanism. authentication (for instance, the purely anonymous TLS cipher
suites), cannot be used for "https" URIs.
For example, because the Alt-Svc header field 5. Requiring Use of TLS
[I-D.nottingham-httpbis-alt-svc] appears in the clear for "http://"
URIs, it is subject to downgrade by attackers that are able to Man-
in-the-Middle the network connection; in its simplest form, an
attacker that wants the connection to remain in the clear need only
strip the Alt-Svc header from responses.
This proposal does not offer a remedy for this risk. However, it's Editors' Note: this is a very rough take on an approach that would
important to note that it is no worse than current use of unencrypted provide a limited form of protection against downgrade attack. It's
HTTP in the face of such active attacks. unclear at this point whether the additional effort (and modest
operational cost) is worthwhile.
Future proposals might attempt to address this risk. The mechanism described in this specification is trival to mount an
active attack against, for two reasons:
4. References o A client that doesn't perform authentication an easy victim of
server impersonation, through man-in-the-middle attacks.
4.1. Normative References o A client that is willing to use cleartext to resolve the resource
will do so if access to any TLS-enabled alternative services is
blocked at the network layer.
[I-D.ietf-httpbis-http2] Given that the primary goal of this specification is to prevent
Belshe, M., Peon, R., Thomson, M., and A. Melnikov, passive attacks, these are not critical failings (especially
"Hypertext Transfer Protocol version 2.0", considering the alternative - HTTP over cleartext). However, a
draft-ietf-httpbis-http2-08 (work in progress), modest form of protection against active attacks can be provided for
November 2013. clients on subsequent connections.
[I-D.ietf-tls-applayerprotoneg] When an alternate service is able to commit to providing service for
Friedl, S., Popov, A., Langley, A., and S. Emile, a particular origin over TLS for a bounded period of time, clients
"Transport Layer Security (TLS) Application Layer Protocol can choose to rely upon its avilability, failing when it cannot be
Negotiation Extension", draft-ietf-tls-applayerprotoneg-03 contacted. Effectively, this makes the alternative service "sticky"
(work in progress), October 2013. in the client.
[I-D.nottingham-httpbis-alt-svc] One drawback with this approach is that clients need to strongly
Nottingham, M., "HTTP Alternate Services", authenticate the alternative service to act upon such a commitment;
draft-nottingham-httpbis-alt-svc-00 (work in progress), otherwise, an attacker could create a persistent denial of service.
October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5.1. The HTTP-TLS Header Field
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. A alternative service can make this commitment by sending a "HTTP-
TLS" header field:
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security HTTP-TLS = 1#parameter
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
4.2. Informative References When it appears in a HTTP response from a strongly authenticated
alternative service, this header field indicates that the
availability of the origin through TLS-protected alternative services
is "sticky", and that the client MUST NOT fall back to cleartext
protocols while this information is considered fresh.
[I-D.ietf-httpbis-p1-messaging] For example:
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-25 (work in progress),
November 2013.
[I-D.mbelshe-httpbis-spdy] HTTP/1.1 200 OK
Belshe, M. and R. Peon, "SPDY Protocol", Content-Type: text/html
draft-mbelshe-httpbis-spdy-00 (work in progress), Cache-Control: 600
February 2012. Age: 30
Date: Thu, 1 May 2014 16:20:09 GMT
HTTP-TLS: ma=3600
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, Note that the commitment is not bound to a particular alternative
May 2000. service; clients SHOULD use other alternative services that they
become aware of, as long as the requirements regarding authentication
and avoidance of cleartext protocols are met.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet When this header field appears in a response, clients MUST strongly
Engineering Task Force Standard Protocols", BCP 61, authenticate the alternative service, as described in Section 3.1 of
RFC 3365, August 2002. [RFC2818], noting the additional requirements in
[I-D.ietf-httpbis-alt-svc]. The header field MUST be ignored if
strong authentication fails.
[RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Y. Serbest, Persisted information expires after a period determined by the value
"Virtual Private LAN Service (VPLS) Interoperability with of the "ma" parameter. See Section 4.2.3 of
Customer Edge (CE) Bridges", RFC 6246, June 2011. [I-D.ietf-httpbis-p6-cache] for details of determining response age.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., ma-parameter = delta-seconds
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
July 2013.
[firesheep] Requests for an origin that has a persisted, unexpired value for
Butler, E., "Firesheep", 2010, "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS
<http://codebutler.com/firesheep/>. connection.
[streetview] 5.2. Operational Considerations
Kravets, D., "The Anatomy of Google's Wi-Fi Sniffing
Debacle", 2012, <http://www.wired.com/threatlevel/2012/05/
google-wifi-fcc-investigation/>.
[xkeyscore] To avoid situations where a persisted value of "HTTP-TLS" causes a
Greenwald, G., "NSA tool collects 'nearly everything a client to be unable to contact a site, clients SHOULD limit the time
user does on the internet'", 2013, <http:// that a value is persisted for a given origin. A hard limit might be
www.theguardian.com/world/2013/jul/31/ set to a month. A lower limit might be appropriate for initial
nsa-top-secret-program-online-data>. observations of "HTTP-TLS"; the certainty that a site has set a
correct value - and the corresponding limit on persistence - can
increase as the value is seen more over time.
Appendix A. Acknowledgements Once a server has indicated that it will support authenticated TLS, a
client MAY use key pinning [I-D.ietf-websec-key-pinning] or any other
mechanism that would otherwise be restricted to use with HTTPS URIs,
provided that the mechanism can be restricted to a single HTTP
origin.
Thanks to Patrick McManus, Eliot Lear, Stephen Farrell, Guy Podjarny, 6. Security Considerations
Stephen Ludin, Erik Nygren, Paul Hoffman and Adam Langley for their 6.1. Security Indicators
feedback and suggestions.
Appendix B. Recent History and Background User Agents MUST NOT provide any special security indicia when an
"http" resource is acquired using TLS. In particular, indicators
that might suggest the same level of security as "https" MUST NOT be
used (e.g., using a "lock device").
One of the design goals for SPDY [I-D.mbelshe-httpbis-spdy] was 6.2. Downgrade Attacks
increasing the use of encryption on the Web, achieved by only
supporting the protocol over a connection protected by TLS [RFC5246].
This was done, in part, because sensitive information - including not A downgrade attack against the negotiation for TLS is possible. With
only login credentials, but also personally identifying information the "HTTP-TLS" header field, this is limited to occasions where
(PII) and even patterns of access - are increasingly prevalent on the clients have no prior information (see Section 6.3), or when
Web, being evident in potentially every HTTP request made. persisted commitments have expired.
Attacks such as FireSheep [firesheep] showed how easy it is to gather For example, because the "Alt-Svc" header field
such information when it is sent in the clear, and incidents such as [I-D.ietf-httpbis-alt-svc] likely appears in an unauthenticated and
Google's collection of unencrypted data by its StreetView Cars unencrypted channel, it is subject to downgrade by network attackers.
[streetview] further illustrated the risks. In its simplest form, an attacker that wants the connection to remain
in the clear need only strip the "Alt-Svc" header field from
responses.
In adopting SPDY as the basis of HTTP/2 [I-D.ietf-httpbis-http2], the As long as a client is willing to use cleartext TCP to contact a
HTTPbis Working Group agreed not to make TLS mandatory to implement server, these attacks are possible. The "HTTP-TLS" header field
(MtI) or mandatory to use (MtU) in our charter, despite an IETF provides an imperfect mechanism for establishing a commitment. The
policy to prefer the "best security available" [RFC3365]. advantage is that this only works if a previous connection is
established where an active attacker was not present. A continuously
present active attacker can either prevent the client from ever using
TLS, or offer a self-signed certificate. This would prevent the
client from ever seeing the "HTTP-TLS" header field, or if the header
field is seen, from successfully validating and persisting it.
There were a variety of reasons for this, but most significantly, 6.3. Privacy Considerations
HTTP is used for much more than the traditional browsing case, and
encryption is not needed for all of these uses. Making encryption
MtU or MtI was seen as unlikely to succeed because of the wide
deployment of HTTP URIs.
However, since making that decision, there have been developments Clients that persist state for origins can be tracked over time based
that have caused the Working Group to discuss these issues again: on their use of this information. Persisted information can be
cleared to reduce the ability of servers to track clients. A browser
client MUST clear persisted all alternative service information when
clearing other origin-based state (i.e., cookies).
1. Active contributors to some browser implementations have stated 7. References
that their products will not use HTTP/2 over unencrypted
connections. If this eventuates, it will prevent wide deployment
of the new protocol (i.e., it couldn't be used with those
products for HTTP URIs; only HTTPS URIs).
2. It has been reported that surveillance of HTTP traffic takes
place on a broad scale [xkeyscore]. While the IETF does not take
a formal, moral position on wiretapping, we do have a strongly
held belief "that both commercial development of the Internet and
adequate privacy for its users against illegal intrusion requires
the wide availability of strong cryptographic technology"
[RFC2804]. This requirement for privacy is further reinforced by
[RFC6973].
As a result, we decided to revisit the issue of how encryption is 7.1. Normative References
used in HTTP/2.0 at IETF87.
Appendix C. Frequently Asked Questions [I-D.ietf-httpbis-alt-svc]
C.1. Will this make encryption mandatory in HTTP/2.0? Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", draft-ietf-httpbis-alt-svc-01 (work
in progress), April 2014.
Not in the sense that this proposal would have it required (with a [I-D.ietf-httpbis-http2]
MUST) in the specification. Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-12 (work in
progress), April 2014.
What might happen, however, is that some browser implementers will [I-D.ietf-httpbis-p6-cache]
take the flexibility that this approach grants and decide to not Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
negotiate for HTTP/2.0 without one of the encryption profiles. That Transfer Protocol (HTTP/1.1): Caching", draft-ietf-
means that servers would need to implement one of the encryption- httpbis-p6-cache-26 (work in progress), February 2014.
enabling profiles to interoperate using HTTP/2.0 for HTTP URIs.
C.2. No certificate checks? Really? [I-D.ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-13
(work in progress), May 2014.
h2r has the effect of relaxing certificate checks on "http://" - but [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
not "https://" - URIs when TLS is in use. Since TLS isn't in use for Requirement Levels", BCP 14, RFC 2119, March 1997.
any "http://" URIs today, there is no net loss of security, and we
gain some privacy from passive attacks.
This makes TLS significantly simpler to deploy for servers; they are [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
able to use a self-signed certificate.
Additionally, it is possible to detect some attacks by remembering [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
what certificate is used in the past "pinning" or third-party (TLS) Protocol Version 1.2", RFC 5246, August 2008.
verification of the certificate in use. This may offer a way to gain
stronger authentication of the origin server's identity, and mitigate
downgrade attacks (although doing so is out of the scope of this
document).
C.3. Why do this if a downgrade attack is so easy? 7.2. Informative References
There are many attack scenarios (e.g., third parties in coffee shops) [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
where active attacks are not feasible, or much more difficult. 2011.
Additionally, active attacks can often be detected, because they [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
change protocol interactions; as such, they bring a risk of Attack", BCP 188, RFC 7258, May 2014.
discovery.
C.4. Why Have separate relaxed protocol identifiers? Appendix A. Acknowledgements
If all implementations agree that using TLS for "http://" URIs always Thanks to Patrick McManus, Eliot Lear, Stephen Farrell, Guy Podjarny,
means that the certificate checks are "relaxed", it could be that Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla
there is no need for a separate protocol identifier. However, this and Richard Barnes for their feedback and suggestions.
needs to be discussed.
Author's Address Authors' Addresses
Mark Nottingham Mark Nottingham
Email: mnot@mnot.net Email: mnot@mnot.net
URI: http://www.mnot.net/ URI: http://www.mnot.net/
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
 End of changes. 73 change blocks. 
282 lines changed or deleted 249 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/