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]