idnits 2.17.1 draft-ietf-httpbis-http2-encryption-02.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 (June 15, 2015) is 3237 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-07 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Experimental M. Thomson 5 Expires: December 17, 2015 Mozilla 6 June 15, 2015 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-02 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 December 17, 2015. 34 Copyright Notice 36 Copyright (c) 2015 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 . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6.1. Security Indicators . . . . . . . . . . . . . . . . . . . 7 62 6.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 7 63 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 8 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 Serving "https" URIs require acquiring and configuring a valid 79 certificate, which means that some deployments find supporting TLS 80 difficult. This document describes a usage model whereby sites can 81 serve "http" URIs over TLS without being required to support strong 82 server authentication. 84 Opportunistic Security [RFC7435] does not provide the same guarantees 85 as using TLS with "https" URIs; it is vulnerable to active attacks, 86 and does not change the security context of the connection. 87 Normally, users will not be able to tell that it is in use (i.e., 88 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. 93 1.1. Goals and Non-Goals 95 The immediate goal is to make the use of HTTP more robust in the face 96 of pervasive passive monitoring [RFC7258]. 98 A secondary goal is to limit the potential for active attacks. It is 99 not intended to offer the same level of protection as afforded to 100 "https" URIs, but instead to increase the likelihood that an active 101 attack can be detected. 103 A final (but significant) goal is to provide for ease of 104 implementation, deployment and operation. This mechanism is expected 105 to have a minimal impact upon performance, and a trivial 106 administrative effort to configure. 108 1.2. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Using HTTP URIs over TLS 116 An origin server that supports the resolution of "http" URIs can 117 indicate support for this specification by providing an alternative 118 service advertisement [I-D.ietf-httpbis-alt-svc] for a protocol 119 identifier that uses TLS, such as "h2" [RFC7540]. 121 A client that receives such an advertisement MAY make future requests 122 intended for the associated origin ([RFC6454]) to the identified 123 service (as specified by [I-D.ietf-httpbis-alt-svc]). 125 A client that places the importance of protection against passive 126 attacks over performance might choose to withhold requests until an 127 encrypted connection is available. However, if such a connection 128 cannot be successfully established, the client can resume its use of 129 the cleartext connection. 131 A client can also explicitly probe for an alternative service 132 advertisement by sending a request that bears little or no sensitive 133 information, such as one with the OPTIONS method. Likewise, clients 134 with existing alternative services information could make such a 135 request before they expire, in order minimize the delays that might 136 be incurred. 138 3. Server Authentication 140 By their nature, "http" URIs do not require cryptographically strong 141 server authentication; that is only implied by "https" URIs. 142 Furthermore, doing so (as per [RFC2818]) creates a number of 143 operational challenges. For these reasons, server authentication is 144 not mandatory for "http" URIs when using the mechanism described in 145 this specification. 147 When connecting to an alternative service for an "http" URI, clients 148 are not required to perform the server authentication procedure 149 described in Section 3.1 of [RFC2818]. The server certificate, if 150 one is proffered by the alternative service, is not necessarily 151 checked for validity, expiration, issuance by a trusted certificate 152 authority or matched against the name in the URI. Therefore, the 153 alternative service can provide any certificate, or even select TLS 154 cipher suites that do not include authentication. 156 A client MAY perform additional checks on the offered certificate if 157 the server does not select an unauthenticated TLS cipher suite. This 158 document doesn't define any such checks, though clients could be 159 configured with a policy that defines what is acceptable. 161 As stipulated by [I-D.ietf-httpbis-alt-svc], clients MUST NOT use 162 alternative services with a host other than the origin's, unless the 163 alternative service itself is strongly authenticated (as the origin's 164 host); for example, using TLS with a certificate that validates as 165 per [RFC2818]. 167 4. Interaction with "https" URIs 169 When using alternative services, requests for resources identified by 170 both "http" and "https" URIs might use the same connection, because 171 HTTP/2 permits requests for multiple origins on the same connection. 173 Since "https" URIs rely on server authentication, a connection that 174 is initially created for "http" URIs without authenticating the 175 server cannot be used for "https" URIs until the server certificate 176 is successfully authenticated. Section 3.1 of [RFC2818] describes 177 the basic mechanism, though the authentication considerations in 178 [I-D.ietf-httpbis-alt-svc] also apply. 180 Connections that are established without any means of server 181 authentication (for instance, the purely anonymous TLS cipher 182 suites), cannot be used for "https" URIs. 184 5. Requiring Use of TLS 186 Editors' Note: this is a very rough take on an approach that would 187 provide a limited form of protection against downgrade attack. It's 188 unclear at this point whether the additional effort (and modest 189 operational cost) is worthwhile. 191 The mechanism described in this specification is trivial to mount an 192 active attack against, for two reasons: 194 o A client that doesn't perform authentication is an easy victim of 195 server impersonation, through man-in-the-middle attacks. 197 o A client that is willing to use HTTP over cleartext to resolve the 198 resource will do so if access to any TLS-enabled alternative 199 services is blocked at the network layer. 201 Given that the primary goal of this specification is to prevent 202 passive attacks, these are not critical failings (especially 203 considering the alternative - HTTP over cleartext). However, a 204 modest form of protection against active attacks can be provided for 205 clients on subsequent connections. 207 When an alternative service is able to commit to providing service 208 for a particular origin over TLS for a bounded period of time, 209 clients can choose to rely upon its availability, failing when it 210 cannot be contacted. Effectively, this makes the choice to use a 211 secured protocol "sticky" in the client. 213 5.1. The HTTP-TLS Header Field 215 A alternative service can make this commitment by sending a "HTTP- 216 TLS" header field, described here using the '#' ABNF extension 217 defined in Section 7 of [RFC7230]: 219 HTTP-TLS = 1#parameter 221 When it appears in a HTTP response from a strongly authenticated 222 alternative service, this header field indicates that the 223 availability of the origin through TLS-protected alternative services 224 is "sticky", and that the client MUST NOT fall back to cleartext 225 protocols while this information is considered fresh. 227 For example: 229 GET /index.html HTTP/1.1 230 Host: example.com 232 HTTP/1.1 200 OK 233 Content-Type: text/html 234 Cache-Control: max-age=600 235 Age: 30 236 Date: Thu, 1 May 2014 16:20:09 GMT 237 HTTP-TLS: ma=3600 239 This header field creates a commitment from the origin [RFC6454] of 240 the associated resource (in the example, "http://example.com"). For 241 the duration of the commitment, clients SHOULD strongly authenticate 242 the server for all subsequent requests made to that origin, though 243 this creates some risks for clients (see Section 5.2). 245 Authentication for HTTP over TLS is described in Section 3.1 of 246 [RFC2818], noting the additional requirements in Section 2.1 of 247 [I-D.ietf-httpbis-alt-svc]. The header field MUST be ignored if 248 strong authentication fails; otherwise, an attacker could create a 249 persistent denial of service by falsifying a commitment. 251 The commitment to use authenticated TLS persists for a period 252 determined by the value of the "ma" parameter. See Section 4.2.3 of 253 [RFC7234] for details of determining response age. 255 ma-parameter = delta-seconds 257 The commitment made by the "HTTP-TLS" header field applies only to 258 the origin of the resource that generates the "HTTP-TLS" header 259 field. 261 Requests for an origin that has a persisted, unexpired value for 262 "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS 263 connection. 265 Note that the commitment is not bound to a particular alternative 266 service. Clients SHOULD use alternative services that they become 267 aware of. However, clients MUST NOT use an unauthenticated 268 alternative service for an origin with this commitment. Where there 269 is an active commitment, clients MAY instead ignore advertisements 270 for unsecured alternatives services. 272 5.2. Operational Considerations 274 To avoid situations where a persisted value of "HTTP-TLS" causes a 275 client to be unable to contact a site, clients SHOULD limit the time 276 that a value is persisted for a given origin. A lower limit might be 277 appropriate for initial observations of "HTTP-TLS"; the certainty 278 that a site has set a correct value - and the corresponding limit on 279 persistence - can increase as the value is seen more over time. 281 Once a server has indicated that it will support authenticated TLS, a 282 client MAY use key pinning [RFC7469] or any other mechanism that 283 would otherwise be restricted to use with "https" URIs, provided that 284 the mechanism can be restricted to a single HTTP 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 used for opportunistically secured requests. 334 7. References 336 7.1. Normative References 338 [I-D.ietf-httpbis-alt-svc] 339 mnot, m., McManus, P., and J. Reschke, "HTTP Alternative 340 Services", draft-ietf-httpbis-alt-svc-07 (work in 341 progress), May 2015. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 345 RFC2119, March 1997, 346 . 348 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 349 RFC2818, May 2000, 350 . 352 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 353 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 354 RFC5246, August 2008, 355 . 357 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10 358 .17487/RFC6454, December 2011, 359 . 361 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 362 (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10 363 .17487/RFC7230, June 2014, 364 . 366 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 367 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10 368 .17487/RFC7234, June 2014, 369 . 371 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 372 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 373 2015, . 375 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 376 Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/ 377 RFC7540, May 2015, 378 . 380 7.2. Informative References 382 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 383 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 384 2014, . 386 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 387 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 388 December 2014, . 390 Appendix A. Acknowledgements 392 Thanks to Patrick McManus, Eliot Lear, Stephen Farrell, Guy Podjarny, 393 Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla 394 and Richard Barnes for their feedback and suggestions. 396 Authors' Addresses 398 Mark Nottingham 400 Email: mnot@mnot.net 401 URI: http://www.mnot.net/ 403 Martin Thomson 404 Mozilla 406 Email: martin.thomson@gmail.com