idnits 2.17.1 draft-thomson-httpbis-http-tls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 14, 2014) is 3635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6797' is defined on line 257, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-01 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-13 == Outdated reference: A later version (-03) exists of draft-nottingham-http2-encryption-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBIS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track May 14, 2014 5 Expires: November 15, 2014 7 Using Transport Layer Security for http URIs 8 draft-thomson-httpbis-http-tls-00 10 Abstract 12 This describes how HTTP URIs can be resolved using Transport Layer 13 Security (TLS). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 15, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 51 2. Alternative Services . . . . . . . . . . . . . . . . . . . . 2 52 3. Server Authentication . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Interaction with HTTPS URIs . . . . . . . . . . . . . . . 3 54 4. Persisting use of TLS . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 8.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The resolution of HTTP URIs [I-D.ietf-httpbis-p1-messaging] provides 66 essentially no security guarantees. This document describes a 67 mechanism that would grant a measure of protection against passive 68 monitoring by opportunistically using Transport Layer Security (TLS) 69 [RFC5246]. 71 This document describes a ways that alternative services 72 [I-D.ietf-httpbis-alt-svc] can be used in combination with HTTP/2 73 [I-D.ietf-httpbis-http2] or HTTP/1.1 [I-D.ietf-httpbis-p1-messaging] 74 over TLS [RFC2818] to resolve HTTP URIs using TLS. 76 A strawman proposal that enables some protection against active 77 attacks, is included in Section 4. 79 1.1. Conventions and Terminology 81 At times, this document falls back on shorthands for establishing 82 interoperability requirements on implementations: the capitalized 83 words "MUST", "SHOULD" and "MAY". These terms are defined in 84 [RFC2119]. 86 2. Alternative Services 88 A server that supports the resolution of HTTP URIs can provide an 89 alternative service advertisement [I-D.ietf-httpbis-alt-svc] for a 90 protocol that uses TLS, such as "h2" ([I-D.ietf-httpbis-http2]), or 91 "http/1.1" ([RFC2818]). 93 A client that sees this advertisement can direct future requests for 94 the associated origin to the alternative service. 96 A client that places the importance of passive protections over 97 performance might choose to send no further requests over cleartext 98 connections if it detects the alternative service advertisement. If 99 the alternative service cannot be successfully connected, the client 100 might resume its use of the cleartext connection. 102 A client can also explicitly probe for an alternative service 103 advertisement by sending a request that bears little or no sensitive 104 information, such as one with the "OPTIONS" method. Clients with 105 expired alternative services information could make a similar request 106 in parallel to an attempt to contact an alternative service, to 107 minimize the delays that might be incurred by failing to contact the 108 alternative service. 110 3. Server Authentication 112 There are no expectations with respect to security when it comes to 113 resolving HTTP URIs. Requiring server authentication, as described 114 in [RFC2818], creates a number of deployment challenges that would 115 adversely affect adoption. Therefore, server authentication is not 116 mandatory for HTTP URIs. 118 When connecting to a service, clients do not perform the server 119 authentication procedure described in Section 3.1 of [RFC2818]. A 120 server is therefore able to provide any certificate, or even select 121 TLS cipher suites that do not include authentication. 123 A client MAY perform additional checks on the certificate that it is 124 offered (if the server does not select an unauthenticated TLS cipher 125 suite). For instance, a client could examine the certificate to see 126 if it has changed over time. 128 3.1. Interaction with HTTPS URIs 130 A service that is discovered to support HTTP URIs might concurrently 131 support HTTPS URIs. HTTP/2 permits the sending of requests for 132 multiple origins (see [RFC6454]) on the one connection. When using 133 alternative services, both HTTP and HTTPS URIs can be sent on the 134 same connection. 136 HTTPS URIs rely on server authentication. Therefore, if a connection 137 is initially created without authenticating the server, requests for 138 HTTPS resources cannot be sent over that connection until the server 139 certificate is successfully authenticated. Section 3.1 of [RFC2818] 140 describes the basic mechanism, though the authentication 141 considerations in [I-D.ietf-httpbis-alt-svc] could also apply. 143 4. Persisting use of TLS 145 [[Open Issue: it seems desirable that this could become sticky to 146 avoid downgrade attacks. Here's a strawman proposal for dealing with 147 that.]] 149 Two factors ensure that active attacks are trivial to mount: 151 o A client that doesn't perform authentication an easy victim of 152 server impersonation, through man-in-the-middle attacks. 154 o A client that is willing to use cleartext to resolve the resource 155 will do so if access to any TLS-enabled alternative services is 156 blocked at the network layer. 158 Both of these issues can be limited by having a server make a 159 commitment to providing service over TLS in future requests. A 160 server makes this commitment by sending a "HTTP-TLS" header field. 162 HTTP/1.1 200 OK 163 Content-Type: text/html 164 Cache-Control: 600 165 Age: 30 166 Date: Thu, 1 May 2014 16:20:09 GMT 167 HTTP-TLS: ma=3600 169 A client that has has not authenticated the server MAY do so when it 170 sees the "HTTP-TLS" header field. The procedure described in 171 Section 3.1 of [RFC2818] MUST be used, without regard to the value of 172 the alternative services. If server authentication is successful, 173 the client can persistently store a record that the requested origin 174 [RFC6454] can be retrieved over TLS. 176 HTTP-TLS = 1#parameter 178 Persisted information expires after a period determined by the value 179 of the "ma" parameter. See Section 4.2.3 of 180 [I-D.ietf-httpbis-p6-cache] for details of determining response age. 182 ma-parameter = delta-seconds 184 Requests for an origin that has a persisted, unexpired value for 185 "HTTP-TLS" MUST fail if they cannot be made over TLS. 187 To avoid situations where a persisted value of "HTTP-TLS" causes a 188 client to be unable to contact a site, clients SHOULD limit the time 189 that a value is persisted for a given origin. A hard limit might be 190 set to a month. A lower limit might be appropriate for initial 191 occurrences of "HTTP-TLS"; the certainty that a site has set a 192 correct value - and the corresponding limit on persistence - can 193 increase as the value is seen more over time. 195 Once a server has indicated that it will support authenticated TLS, a 196 client MAY use key pinning [I-D.ietf-websec-key-pinning] or any other 197 mechanism that would otherwise be restricted to use with HTTPS URIs, 198 provided that the mechanism can be restricted to a single HTTP 199 origin. 201 5. Security Considerations 203 The basic mechanisms here do absolutely nothing against an active 204 attack. Section 4 describes a system whereby return business can be 205 protected from active attack. 207 Clients that persist state for origins can be tracked over time based 208 on their use of this information. Persisted information can be 209 cleared to reduce the ability of servers to track clients. A browser 210 client MUST clear persisted all alternative service information when 211 clearing other origin-based state (i.e., cookies). 213 6. IANA Considerations 215 TODO: Register HTTP-TLS if it makes sense to do so. 217 7. Acknowledgements 219 Mark Nottingham provided useful input, in particular 220 [I-D.nottingham-http2-encryption]. 222 8. References 224 8.1. Normative References 226 [I-D.ietf-httpbis-alt-svc] 227 mnot, m., McManus, P., and J. Reschke, "HTTP Alternative 228 Services", draft-ietf-httpbis-alt-svc-01 (work in 229 progress), April 2014. 231 [I-D.ietf-httpbis-http2] 232 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 233 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 234 progress), April 2014. 236 [I-D.ietf-httpbis-p1-messaging] 237 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 238 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 239 httpbis-p1-messaging-26 (work in progress), February 2014. 241 [I-D.ietf-httpbis-p6-cache] 242 Fielding, R., mnot, m., and J. Reschke, "Hypertext 243 Transfer Protocol (HTTP/1.1): Caching", draft-ietf- 244 httpbis-p6-cache-26 (work in progress), February 2014. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 251 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 252 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 254 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 255 2011. 257 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 258 Transport Security (HSTS)", RFC 6797, November 2012. 260 8.2. Informative References 262 [I-D.ietf-websec-key-pinning] 263 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 264 Extension for HTTP", draft-ietf-websec-key-pinning-13 265 (work in progress), May 2014. 267 [I-D.nottingham-http2-encryption] 268 mnot, m., "Opportunistic Encryption for HTTP URIs", draft- 269 nottingham-http2-encryption-02 (work in progress), 270 December 2013. 272 Author's Address 274 Martin Thomson 275 Mozilla 276 331 E Evelyn Street 277 Mountain View, CA 94041 278 US 280 Email: martin.thomson@gmail.com