Internet DRAFT - draft-thomson-httpbis-http-tls
draft-thomson-httpbis-http-tls
HTTPBIS M. Thomson
Internet-Draft Mozilla
Intended status: Standards Track May 14, 2014
Expires: November 15, 2014
Using Transport Layer Security for http URIs
draft-thomson-httpbis-http-tls-00
Abstract
This describes how HTTP URIs can be resolved using Transport Layer
Security (TLS).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 15, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thomson Expires November 15, 2014 [Page 1]
Internet-Draft TLS for http: May 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Alternative Services . . . . . . . . . . . . . . . . . . . . 2
3. Server Authentication . . . . . . . . . . . . . . . . . . . . 3
3.1. Interaction with HTTPS URIs . . . . . . . . . . . . . . . 3
4. Persisting use of TLS . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The resolution of HTTP URIs [I-D.ietf-httpbis-p1-messaging] provides
essentially no security guarantees. This document describes a
mechanism that would grant a measure of protection against passive
monitoring by opportunistically using Transport Layer Security (TLS)
[RFC5246].
This document describes a ways that alternative services
[I-D.ietf-httpbis-alt-svc] can be used in combination with HTTP/2
[I-D.ietf-httpbis-http2] or HTTP/1.1 [I-D.ietf-httpbis-p1-messaging]
over TLS [RFC2818] to resolve HTTP URIs using TLS.
A strawman proposal that enables some protection against active
attacks, is included in Section 4.
1.1. Conventions and Terminology
At times, this document falls back on shorthands for establishing
interoperability requirements on implementations: the capitalized
words "MUST", "SHOULD" and "MAY". These terms are defined in
[RFC2119].
2. Alternative Services
A server that supports the resolution of HTTP URIs can provide an
alternative service advertisement [I-D.ietf-httpbis-alt-svc] for a
protocol that uses TLS, such as "h2" ([I-D.ietf-httpbis-http2]), or
"http/1.1" ([RFC2818]).
A client that sees this advertisement can direct future requests for
the associated origin to the alternative service.
Thomson Expires November 15, 2014 [Page 2]
Internet-Draft TLS for http: May 2014
A client that places the importance of passive protections over
performance might choose to send no further requests over cleartext
connections if it detects the alternative service advertisement. If
the alternative service cannot be successfully connected, the client
might resume its use of the cleartext connection.
A client can also explicitly probe for an alternative service
advertisement by sending a request that bears little or no sensitive
information, such as one with the "OPTIONS" method. Clients with
expired alternative services information could make a similar request
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.
3. Server Authentication
There are no expectations with respect to security when it comes to
resolving HTTP URIs. Requiring server authentication, as described
in [RFC2818], creates a number of deployment challenges that would
adversely affect adoption. Therefore, server authentication is not
mandatory for HTTP URIs.
When connecting to a service, clients do not perform the server
authentication procedure described in Section 3.1 of [RFC2818]. A
server is therefore able to provide any certificate, or even select
TLS cipher suites that do not include authentication.
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.
3.1. Interaction with HTTPS URIs
A service that is discovered to support HTTP URIs might concurrently
support HTTPS URIs. HTTP/2 permits the sending of requests for
multiple origins (see [RFC6454]) on the one connection. When using
alternative services, both HTTP and HTTPS URIs can be sent on the
same connection.
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.
Thomson Expires November 15, 2014 [Page 3]
Internet-Draft TLS for http: May 2014
4. Persisting use of TLS
[[Open Issue: it seems desirable that this could become sticky to
avoid downgrade attacks. Here's a strawman proposal for dealing with
that.]]
Two factors ensure that active attacks are trivial to mount:
o A client that doesn't perform authentication an easy victim of
server impersonation, through man-in-the-middle attacks.
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.
Both of these issues can be limited by having a server make a
commitment to providing service over TLS in future requests. A
server makes this commitment by sending a "HTTP-TLS" header field.
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: 600
Age: 30
Date: Thu, 1 May 2014 16:20:09 GMT
HTTP-TLS: ma=3600
A client that has has not authenticated the server MAY do so when it
sees the "HTTP-TLS" header field. The procedure described in
Section 3.1 of [RFC2818] MUST be used, without regard to the value of
the alternative services. If server authentication is successful,
the client can persistently store a record that the requested origin
[RFC6454] can be retrieved over TLS.
HTTP-TLS = 1#parameter
Persisted information expires after a period determined by the value
of the "ma" parameter. See Section 4.2.3 of
[I-D.ietf-httpbis-p6-cache] for details of determining response age.
ma-parameter = delta-seconds
Requests for an origin that has a persisted, unexpired value for
"HTTP-TLS" MUST fail if they cannot be made over TLS.
To avoid situations where a persisted value of "HTTP-TLS" causes a
client to be unable to contact a site, clients SHOULD limit the time
that a value is persisted for a given origin. A hard limit might be
set to a month. A lower limit might be appropriate for initial
Thomson Expires November 15, 2014 [Page 4]
Internet-Draft TLS for http: May 2014
occurrences 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.
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.
5. Security Considerations
The basic mechanisms here do absolutely nothing against an active
attack. Section 4 describes a system whereby return business can be
protected from active attack.
Clients that persist state for origins can be tracked over time based
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).
6. IANA Considerations
TODO: Register HTTP-TLS if it makes sense to do so.
7. Acknowledgements
Mark Nottingham provided useful input, in particular
[I-D.nottingham-http2-encryption].
8. References
8.1. Normative References
[I-D.ietf-httpbis-alt-svc]
mnot, m., McManus, P., and J. Reschke, "HTTP Alternative
Services", draft-ietf-httpbis-alt-svc-01 (work in
progress), April 2014.
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-12 (work in
progress), April 2014.
Thomson Expires November 15, 2014 [Page 5]
Internet-Draft TLS for http: May 2014
[I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", draft-ietf-
httpbis-p1-messaging-26 (work in progress), February 2014.
[I-D.ietf-httpbis-p6-cache]
Fielding, R., mnot, m., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", draft-ietf-
httpbis-p6-cache-26 (work in progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
8.2. Informative References
[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.
[I-D.nottingham-http2-encryption]
mnot, m., "Opportunistic Encryption for HTTP URIs", draft-
nottingham-http2-encryption-02 (work in progress),
December 2013.
Author's Address
Martin Thomson
Mozilla
331 E Evelyn Street
Mountain View, CA 94041
US
Email: martin.thomson@gmail.com
Thomson Expires November 15, 2014 [Page 6]
