idnits 2.17.1 draft-ietf-httpbis-http2-encryption-10.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 date (January 31, 2017) is 2641 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7469' is defined on line 394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 8 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: August 4, 2017 Mozilla 6 January 31, 2017 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-10 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 Note to Readers 19 Discussion of this draft takes place on the HTTP working group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 23 Working Group information can be found at http://httpwg.github.io/ ; 24 source code and issues list for this draft can be found at 25 https://github.com/httpwg/http-extensions/labels/opp-sec . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 4, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 3 63 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 64 2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3 65 2.1. Alternative Server Opt-In . . . . . . . . . . . . . . . . 4 66 2.2. Interaction with "https" URIs . . . . . . . . . . . . . . 5 67 2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 4.1. Security Indicators . . . . . . . . . . . . . . . . . . . 6 71 4.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Privacy Considerations . . . . . . . . . . . . . . . . . 7 73 4.4. Confusion Regarding Request Scheme . . . . . . . . . . . 7 74 4.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 7 75 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 5.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 This document describes a use of HTTP Alternative Services [RFC7838] 84 to decouple the URI scheme from the use and configuration of 85 underlying encryption, allowing a "http" URI [RFC7230] to be accessed 86 using Transport Layer Security (TLS) [RFC5246] opportunistically. 88 Serving "https" URIs requires avoiding Mixed Content 89 [W3C.CR-mixed-content-20160802], which is problematic in many 90 deployments. This document describes a usage model whereby sites can 91 serve "http" URIs over TLS, thereby avoiding these issues, while 92 still providing protection against passive attacks. 94 Opportunistic Security [RFC7435] does not provide the same guarantees 95 as using TLS with "https" URIs; it is vulnerable to active attacks, 96 and does not change the security context of the connection. 98 Normally, users will not be able to tell that it is in use (i.e., 99 there will be no "lock icon"). 101 1.1. Goals and Non-Goals 103 The immediate goal is to make the use of HTTP more robust in the face 104 of pervasive passive monitoring [RFC7258]. 106 A secondary (but significant) goal is to provide for ease of 107 implementation, deployment and operation. This mechanism is expected 108 to have a minimal impact upon performance, and require a trivial 109 administrative effort to configure. 111 Preventing active attacks (such as a Man-in-the-Middle) is a non-goal 112 for this specification. Furthermore, this specification is not 113 intended to replace or offer an alternative to "https", since it both 114 prevents active attacks and invokes a more stringent security model 115 in most clients. 117 1.2. Notational Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Using HTTP URIs over TLS 125 An origin server that supports the resolution of "http" URIs can 126 indicate support for this specification by providing an alternative 127 service advertisement [RFC7838] for a protocol identifier that uses 128 TLS, such as "h2" [RFC7540]. Such a protocol MUST include an 129 explicit indication of the scheme of the resource. This excludes 130 HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute 131 form of a URI in requests to origin servers (see Section 5.3.1 of 132 [RFC7230]). 134 A client that receives such an advertisement MAY make future requests 135 intended for the associated origin [RFC6454] to the identified 136 service (as specified by [RFC7838]), provided that the alternative 137 service opts in as described in Section 2.1. 139 A client that places the importance of protection against passive 140 attacks over performance might choose to withhold requests until an 141 encrypted connection is available. However, if such a connection 142 cannot be successfully established, the client can resume its use of 143 the cleartext connection. 145 A client can also explicitly probe for an alternative service 146 advertisement by sending a request that bears little or no sensitive 147 information, such as one with the OPTIONS method. Likewise, clients 148 with existing alternative services information could make such a 149 request before they expire, in order minimize the delays that might 150 be incurred. 152 Client certificates are not meaningful for URLs with the "http" 153 scheme, and therefore clients creating new TLS connections to 154 alternative services for the purposes of this specification MUST NOT 155 present them. A server that also provides "https" resources on the 156 same port can request a certificate during the TLS handshake, but it 157 MUST NOT abort the handshake if the client does not provide one. 159 2.1. Alternative Server Opt-In 161 It is possible that the server might become confused about whether 162 requests' URLs have a "http" or "https" scheme, for various reasons; 163 see Section 4.4. To ensure that the alternative service has opted 164 into serving "http" URLs over TLS, clients are required to perform 165 additional checks before directing "http" requests to it. 167 Clients MUST NOT send "http" requests over a secured connection, 168 unless the chosen alternative service presents a certificate that is 169 valid for the origin as defined in [RFC2818]. Using an authenticated 170 alternative service establishes "reasonable assurances" for the 171 purposes of {RFC7838}}. In addition to authenticating the server, 172 the client MUST have obtained a valid http-opportunistic response for 173 an origin (as per Section 2.3) using the authenticated connection. 174 An exception to the latter restriction is made for requests for the 175 "http-opportunistic" well-known URI. 177 For example, assuming the following request is made over a TLS 178 connection that is successfully authenticated for those origins, the 179 following request/response pair would allow requests for the origins 180 "http://www.example.com" or "http://example.com" to be sent using a 181 secured connection: 183 HEADERS 184 + END_STREAM 185 + END_HEADERS 186 :method = GET 187 :scheme = http 188 :path = /.well-known/http-opportunistic 189 host: example.com 191 HEADERS 192 :status = 200 193 content-type = application/json 194 DATA 195 + END_STREAM 196 [ "http://www.example.com", "http://example.com" ] 198 Though this document describes multiple origins, this is only for 199 operational convenience. Only a request made to an origin (over an 200 authenticated connection) can be used to acquire this resource for 201 that origin. Thus in the example, the request to 202 "http://example.com" cannot be assumed to also provide an http- 203 opportunistic response for "http://www.example.com". 205 2.2. Interaction with "https" URIs 207 Clients MUST NOT send "http" requests and "https" requests on the 208 same connection. Similarly, clients MUST NOT send "http" requests 209 for multiple origins on the same connection. 211 2.3. The "http-opportunistic" well-known URI 213 This specification defines the "http-opportunistic" well-known URI 214 [RFC5785]. A client is said to have a valid http-opportunistic 215 response for a given origin when: 217 o The client has requested the well-known URI from the origin over 218 an authenticated connection and a 200 (OK) response was provided, 219 and 221 o That response is fresh [RFC7234] (potentially through revalidation 222 [RFC7232]), and 224 o That response has the media type "application/json", and 226 o That response's payload, when parsed as JSON [RFC7159], contains 227 an array as the root, and 229 o The array contains a string that is a case-insensitive character- 230 for-character match for the origin in question, serialised into 231 Unicode as per Section 6.1 of [RFC6454]. 233 A client MAY treat an "http-opportunistic" resource as invalid if 234 values it contains are not strings. 236 This document does not define semantics for "http-opportunistic" 237 resources on an "https" origin, nor does it define semantics if the 238 resource includes "https" origins. 240 Allowing clients to cache the http-opportunistic resource means that 241 all alternative services need to be able to respond to requests for 242 "http" resources. A client is permitted to use an alternative 243 service without acquiring the http-opportunistic resource from that 244 service. 246 A client MUST NOT use any cached copies of an http-opportunistic 247 resource that was acquired (or revalidated) over an unauthenticated 248 connection. To avoid potential errors, a client can request or 249 revalidate the http-opportunistic resource before using any 250 connection to an alternative service. 252 Clients that use cached http-opportunistic responses MUST ensure that 253 their cache is cleared of any responses that were acquired over an 254 unauthenticated connection. Revalidating an unauthenticated response 255 using an authenticated connection does not ensure the integrity of 256 the response. 258 3. IANA Considerations 260 This specification registers a Well-Known URI [RFC5785]: 262 o URI Suffix: http-opportunistic 264 o Change Controller: IETF 266 o Specification Document(s): Section 2.3 of [this specification] 268 o Related Information: 270 4. Security Considerations 272 4.1. Security Indicators 274 User Agents MUST NOT provide any special security indicia when an 275 "http" resource is acquired using TLS. In particular, indicators 276 that might suggest the same level of security as "https" MUST NOT be 277 used (e.g., a "lock device"). 279 4.2. Downgrade Attacks 281 A downgrade attack against the negotiation for TLS is possible. 283 For example, because the "Alt-Svc" header field [RFC7838] likely 284 appears in an unauthenticated and unencrypted channel, it is subject 285 to downgrade by network attackers. In its simplest form, an attacker 286 that wants the connection to remain in the clear need only strip the 287 "Alt-Svc" header field from responses. 289 4.3. Privacy Considerations 291 Cached alternative services can be used to track clients over time; 292 e.g., using a user-specific hostname. Clearing the cache reduces the 293 ability of servers to track clients; therefore clients MUST clear 294 cached alternative service information when clearing other origin- 295 based state (i.e., cookies). 297 4.4. Confusion Regarding Request Scheme 299 HTTP implementations and applications sometimes use ambient signals 300 to determine if a request is for an "https" resource; for example, 301 they might look for TLS on the stack, or a server port number of 443. 303 This might be due to expected limitations in the protocol (the most 304 common HTTP/1.1 request form does not carry an explicit indication of 305 the URI scheme and the resource might have been developed assuming 306 HTTP/1.1), or it may be because how the server and application are 307 implemented (often, they are two separate entities, with a variety of 308 possible interfaces between them). 310 Any security decisions based upon this information could be misled by 311 the deployment of this specification, because it violates the 312 assumption that the use of TLS (or port 443) means that the client is 313 accessing a HTTPS URI, and operating in the security context implied 314 by HTTPS. 316 Therefore, servers need to carefully examine the use of such signals 317 before deploying this specification. 319 4.5. Server Controls 321 This specification requires that a server send both an Alternative 322 Service advertisement and host content in a well-known location to 323 send HTTP requests over TLS. Servers SHOULD take suitable measures 324 to ensure that the content of the well-known resource remains under 325 their control. Likewise, because the Alt-Svc header field is used to 326 describe policies across an entire origin, servers SHOULD NOT permit 327 user content to set or modify the value of this header. 329 5. References 331 5.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 339 DOI 10.17487/RFC2818, May 2000, 340 . 342 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 343 (TLS) Protocol Version 1.2", RFC 5246, 344 DOI 10.17487/RFC5246, August 2008, 345 . 347 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 348 Uniform Resource Identifiers (URIs)", RFC 5785, 349 DOI 10.17487/RFC5785, April 2010, 350 . 352 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 353 DOI 10.17487/RFC6454, December 2011, 354 . 356 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 357 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 358 2014, . 360 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 361 Protocol (HTTP/1.1): Message Syntax and Routing", 362 RFC 7230, DOI 10.17487/RFC7230, June 2014, 363 . 365 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 366 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 367 DOI 10.17487/RFC7232, June 2014, 368 . 370 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 371 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 372 RFC 7234, DOI 10.17487/RFC7234, June 2014, 373 . 375 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 376 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 377 DOI 10.17487/RFC7540, May 2015, 378 . 380 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 381 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 382 April 2016, . 384 5.2. Informative References 386 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 387 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 388 2014, . 390 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 391 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 392 December 2014, . 394 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 395 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 396 2015, . 398 [W3C.CR-mixed-content-20160802] 399 West, M., "Mixed Content", World Wide Web Consortium CR 400 CR-mixed-content-20160802, August 2016, 401 . 403 Appendix A. Acknowledgements 405 Mike Bishop contributed significant text to this document. 407 Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen 408 Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam 409 Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard 410 Barnes for their feedback and suggestions. 412 Authors' Addresses 414 Mark Nottingham 416 Email: mnot@mnot.net 417 URI: https://www.mnot.net/ 418 Martin Thomson 419 Mozilla 421 Email: martin.thomson@gmail.com