idnits 2.17.1 draft-ietf-httpbis-http2-encryption-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2014) is 3419 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-05 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-16 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Experimental M. Thomson 5 Expires: June 18, 2015 Mozilla 6 December 15, 2014 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-01 11 Abstract 13 This document describes how "http" URIs can be accessed using 14 Transport Layer Security (TLS) to mitigate pervasive monitoring 15 attacks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 18, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 3 53 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 54 2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3 55 3. Server Authentication . . . . . . . . . . . . . . . . . . . . 4 56 4. Interaction with "https" URIs . . . . . . . . . . . . . . . . 4 57 5. Requiring Use of TLS . . . . . . . . . . . . . . . . . . . . 5 58 5.1. The HTTP-TLS Header Field . . . . . . . . . . . . . . . . 5 59 5.2. Operational Considerations . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6.1. Security Indicators . . . . . . . . . . . . . . . . . . . 7 62 6.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 7 63 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 7 64 6.4. Confusion Regarding Request Scheme . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document describes a use of HTTP Alternative Services 74 [I-D.ietf-httpbis-alt-svc] to decouple the URI scheme from the use 75 and configuration of underlying encryption, allowing a "http" URI to 76 be accessed using TLS [RFC5246] opportunistically. 78 Currently, "https" URIs require acquiring and configuring a valid 79 certificate, which means that some deployments find supporting TLS 80 difficult. Therefore, this document describes a usage model whereby 81 sites can serve "http" URIs over TLS without being required to 82 support strong server authentication. 84 Opportunistic Security [I-D.dukhovni-opportunistic-security] does not 85 provide the same guarantees as using TLS with "https" URIs; it is 86 vulnerable to active attacks, and does not change the security 87 context of the connection. Normally, users will not be able to tell 88 that it is in use (i.e., there will be no "lock icon"). 90 By its nature, this technique is vulnerable to active attacks. A 91 mechanism for partially mitigating them is described in Section 5. 92 It does not offer the same level of protection as afforded to "https" 93 URIs, but increases the likelihood that an active attack be detected. 95 1.1. Goals and Non-Goals 97 The immediate goal is to make the use of HTTP more robust in the face 98 of pervasive passive monitoring [RFC7258]. 100 A secondary goal is to limit the potential for active attacks. It is 101 not intended to offer the same level of protection as afforded to 102 "https" URIs, but instead to increase the likelihood that an active 103 attack can be detected. 105 A final (but significant) goal is to provide for ease of 106 implementation, deployment and operation. This mechanism should have 107 a minimal impact upon performance, and should not require extensive 108 administrative effort to configure. 110 1.2. Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Using HTTP URIs over TLS 118 An origin server that supports the resolution of "http" URIs can 119 indicate support for this specification by providing an alternative 120 service advertisement [I-D.ietf-httpbis-alt-svc] for a protocol 121 identifier that uses TLS, such as "h2" [I-D.ietf-httpbis-http2]. 123 A client that receives such an advertisement MAY make future requests 124 intended for the associated origin ([RFC6454]) to the identified 125 service (as specified by [I-D.ietf-httpbis-alt-svc]). 127 A client that places the importance of protection against passive 128 attacks over performance might choose to withhold requests until an 129 encrypted connection is available. However, if such a connection 130 cannot be successfully established, the client MAY resume its use of 131 the cleartext connection. 133 A client can also explicitly probe for an alternative service 134 advertisement by sending a request that bears little or no sensitive 135 information, such as one with the OPTIONS method. Likewise, clients 136 with existing alternative services information could make such a 137 request before they expire, in order minimize the delays that might 138 be incurred. 140 3. Server Authentication 142 By their nature, "http" URIs do not require cryptographically strong 143 server authentication; that is only implied by "https" URIs. 144 Furthermore, doing so (as per [RFC2818]) creates a number of 145 operational challenges. For these reasons, server authentication is 146 not mandatory for "http" URIs when using the mechanism described in 147 this specification. 149 When connecting to an alternative service for an "http" URI, clients 150 are not required to perform the server authentication procedure 151 described in Section 3.1 of [RFC2818]. The server certificate, if 152 one is proffered by the alternative service, is not necessarily 153 checked for validity, expiration, issuance by a trusted certificate 154 authority or matched against the name in the URI. Therefore, the 155 alternative service MAY provide any certificate, or even select TLS 156 cipher suites that do not include authentication. 158 A client MAY perform additional checks on the offered certificate if 159 the server does not select an unauthenticated TLS cipher suite. This 160 document doesn't define any such checks, though clients could be 161 configured with a policy that defines what is acceptable. 163 As stipulated by [I-D.ietf-httpbis-alt-svc], clients MUST NOT use 164 alternative services with a host other than the origin's, unless the 165 alternative service itself is strongly authenticated (as the origin's 166 host); for example, using TLS with a certificate that validates as 167 per [RFC2818]. 169 4. Interaction with "https" URIs 171 When using alternative services, both "http" and "https" URIs might 172 use the same connection, because HTTP/2 permits requests for multiple 173 origins on the same connection. 175 Since "https" URIs rely on server authentication, a connection that 176 is initially created for "http" URIs without authenticating the 177 server cannot be used for "https" URIs until the server certificate 178 is successfully authenticated. Section 3.1 of [RFC2818] describes 179 the basic mechanism, though the authentication considerations in 180 [I-D.ietf-httpbis-alt-svc] also apply. 182 Connections that are established without any means of server 183 authentication (for instance, the purely anonymous TLS cipher 184 suites), cannot be used for "https" URIs. 186 5. Requiring Use of TLS 188 Editors' Note: this is a very rough take on an approach that would 189 provide a limited form of protection against downgrade attack. It's 190 unclear at this point whether the additional effort (and modest 191 operational cost) is worthwhile. 193 The mechanism described in this specification is trival to mount an 194 active attack against, for two reasons: 196 o A client that doesn't perform authentication an easy victim of 197 server impersonation, through man-in-the-middle attacks. 199 o A client that is willing to use cleartext to resolve the resource 200 will do so if access to any TLS-enabled alternative services is 201 blocked at the network layer. 203 Given that the primary goal of this specification is to prevent 204 passive attacks, these are not critical failings (especially 205 considering the alternative - HTTP over cleartext). However, a 206 modest form of protection against active attacks can be provided for 207 clients on subsequent connections. 209 When an alternative service is able to commit to providing service 210 for a particular origin over TLS for a bounded period of time, 211 clients can choose to rely upon its avilability, failing when it 212 cannot be contacted. Effectively, this makes the choice to use a 213 secured protocol "sticky" in the client. 215 5.1. The HTTP-TLS Header Field 217 A alternative service can make this commitment by sending a "HTTP- 218 TLS" header field: 220 HTTP-TLS = 1#parameter 222 When it appears in a HTTP response from a strongly authenticated 223 alternative service, this header field indicates that the 224 availability of the origin through TLS-protected alternative services 225 is "sticky", and that the client MUST NOT fall back to cleartext 226 protocols while this information is considered fresh. 228 For example: 230 GET /index.html HTTP/1.1 231 Host: example.com 233 HTTP/1.1 200 OK 234 Content-Type: text/html 235 Cache-Control: 600 236 Age: 30 237 Date: Thu, 1 May 2014 16:20:09 GMT 238 HTTP-TLS: ma=3600 240 This header field creates a commitment from the origin [RFC6454] of 241 the associated resource (in the example, "http://example.com"). For 242 the duration of the commitment, clients SHOULD strongly authenticate 243 the server for all subsequent requests made to that origin, though 244 this creates some risks for clients Section 5.2. 246 Authentication for HTTP over TLS is described in Section 3.1 of 247 [RFC2818], noting the additional requirements in 248 [I-D.ietf-httpbis-alt-svc]. The header field MUST be ignored if 249 strong authentication fails; otherwise, an attacker could create a 250 persistent denial of service by falsifying a commitment. 252 The commitment to use authenticated TLS persists for a period 253 determined by the value of the "ma" parameter. See Section 4.2.3 of 254 [RFC7234] for details of determining response age. 256 ma-parameter = delta-seconds 258 The commitment made by the "HTTP-TLS" header field applies only to 259 the origin of the resource that generates the "HTTP-TLS" header 260 field. Requests for an origin that has a persisted, unexpired value 261 for "HTTP-TLS" MUST fail if they cannot be made over an authenticated 262 TLS connection. 264 Note that the commitment is not bound to a particular alternative 265 service. Clients SHOULD use alternative services that they become 266 aware of. However, clients MUST NOT use an unauthenticated 267 alternative service for an origin with this commitment. Where there 268 is an active commitment, clients MAY instead ignore advertisements 269 for unsecured alternatives services. 271 5.2. Operational Considerations 273 To avoid situations where a persisted value of "HTTP-TLS" causes a 274 client to be unable to contact a site, clients SHOULD limit the time 275 that a value is persisted for a given origin. A lower limit might be 276 appropriate for initial observations of "HTTP-TLS"; the certainty 277 that a site has set a correct value - and the corresponding limit on 278 persistence - can increase as the value is seen more over time. 280 Once a server has indicated that it will support authenticated TLS, a 281 client MAY use key pinning [I-D.ietf-websec-key-pinning] or any other 282 mechanism that would otherwise be restricted to use with "https" 283 URIs, provided that the mechanism can be restricted to a single HTTP 284 origin. 286 6. Security Considerations 288 6.1. Security Indicators 290 User Agents MUST NOT provide any special security indicia when an 291 "http" resource is acquired using TLS. In particular, indicators 292 that might suggest the same level of security as "https" MUST NOT be 293 used (e.g., using a "lock device"). 295 6.2. Downgrade Attacks 297 A downgrade attack against the negotiation for TLS is possible. With 298 the "HTTP-TLS" header field, this is limited to occasions where 299 clients have no prior information (see Section 6.3), or when 300 persisted commitments have expired. 302 For example, because the "Alt-Svc" header field 303 [I-D.ietf-httpbis-alt-svc] likely appears in an unauthenticated and 304 unencrypted channel, it is subject to downgrade by network attackers. 305 In its simplest form, an attacker that wants the connection to remain 306 in the clear need only strip the "Alt-Svc" header field from 307 responses. 309 Downgrade attacks can be partially mitigated using the "HTTP-TLS" 310 header field, because when it is used, a client can avoid using 311 cleartext to contact a supporting server. However, this only works 312 when a previous connection has been established without an active 313 attacker present; a continuously present active attacker can either 314 prevent the client from ever using TLS, or offer its own certificate. 316 6.3. Privacy Considerations 318 Cached alternative services can be used to track clients over time; 319 e.g., using a user-specific hostname. Clearing the cache reduces the 320 ability of servers to track clients; therefore clients MUST clear 321 cached alternative service information when clearing other origin- 322 based state (i.e., cookies). 324 6.4. Confusion Regarding Request Scheme 326 Many existing HTTP/1.1 implementations use the presence or absence of 327 TLS in the stack to determine whether requests are for "http" or 328 "https" resources. This is necessary in many cases because the most 329 common form of an HTTP/1.1 request does not carry an explicit 330 indication of the URI scheme. 332 HTTP/1.1 MUST NOT be sent over HTTP/1.1 or earlier versions of the 333 protocol. Opportunistically secured HTTP requests MUST include an 334 explicit scheme identifier. 336 7. References 338 7.1. Normative References 340 [I-D.ietf-httpbis-alt-svc] 341 Nottingham, M., McManus, P., and J. Reschke, "HTTP 342 Alternative Services", draft-ietf-httpbis-alt-svc-05 (work 343 in progress), December 2014. 345 [I-D.ietf-httpbis-http2] 346 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 347 Protocol version 2", draft-ietf-httpbis-http2-16 (work in 348 progress), November 2014. 350 [I-D.ietf-websec-key-pinning] 351 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 352 Extension for HTTP", draft-ietf-websec-key-pinning-21 353 (work in progress), October 2014. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 360 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 361 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 363 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 364 2011. 366 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 367 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 368 2014. 370 7.2. Informative References 372 [I-D.dukhovni-opportunistic-security] 373 Dukhovni, V., "Opportunistic Security: Some Protection 374 Most of the Time", draft-dukhovni-opportunistic- 375 security-06 (work in progress), November 2014. 377 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 378 Attack", BCP 188, RFC 7258, May 2014. 380 Appendix A. Acknowledgements 382 Thanks to Patrick McManus, Eliot Lear, Stephen Farrell, Guy Podjarny, 383 Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla 384 and Richard Barnes for their feedback and suggestions. 386 Authors' Addresses 388 Mark Nottingham 390 Email: mnot@mnot.net 391 URI: http://www.mnot.net/ 393 Martin Thomson 394 Mozilla 396 Email: martin.thomson@gmail.com