idnits 2.17.1 draft-ietf-httpbis-http2-encryption-09.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 (December 21, 2016) is 2684 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7469' is defined on line 363, 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: June 24, 2017 Mozilla 6 December 21, 2016 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-09 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 June 24, 2017. 44 Copyright Notice 46 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 6 72 4.3. Privacy Considerations . . . . . . . . . . . . . . . . . 6 73 4.4. Confusion Regarding Request Scheme . . . . . . . . . . . 6 74 4.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 7 75 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 5.2. Informative References . . . . . . . . . . . . . . . . . 8 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. Connections that use client certificates for other 156 reasons MAY be reused, though client certificates MUST NOT affect the 157 responses to requests for "http" resources. 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 per [RFC2818] (this also establishes 170 "reasonable assurances" for the purposes of {RFC7838}}) - and they 171 have obtained a valid http-opportunistic response for an origin (as 172 per Section 2.3). 174 For example, assuming the following request is made over a TLS 175 connection that is successfully authenticated for those origins, the 176 following request/response pair would allow requests for the origins 177 "http://www.example.com" or "http://example.com" to be sent using a 178 secured connection: 180 HEADERS 181 + END_STREAM 182 + END_HEADERS 183 :method = GET 184 :scheme = http 185 :path = /.well-known/http-opportunistic 186 host: example.com 188 HEADERS 189 :status = 200 190 content-type = application/json 191 DATA 192 + END_STREAM 193 [ "http://www.example.com", "http://example.com" ] 195 2.2. Interaction with "https" URIs 197 Clients MUST NOT send "http" requests and "https" requests on the 198 same connection. Similarly, clients MUST NOT send "http" requests 199 for multiple origins on the same connection. 201 2.3. The "http-opportunistic" well-known URI 203 This specification defines the "http-opportunistic" well-known URI 204 [RFC5785]. A client is said to have a valid http-opportunistic 205 response for a given origin when: 207 o The client has obtained a 200 (OK) response for the well-known URI 208 from the origin, and it is fresh [RFC7234] (potentially through 209 revalidation [RFC7232]), and 211 o That response has the media type "application/json", and 213 o That response's payload, when parsed as JSON [RFC7159], contains 214 an array as the root, and 216 o The array contains a string that is a case-insensitive character- 217 for-character match for the origin in question, serialised into 218 Unicode as per Section 6.1 of [RFC6454]. 220 A client MAY treat an "http-opportunistic" resource as invalid if the 221 contains values that are not strings. 223 This document does not define semantics for "http-opportunistic" 224 resources on an "https" origin, nor does it define semantics if the 225 resource includes "https" origins. 227 3. IANA Considerations 229 This specification registers a Well-Known URI [RFC5785]: 231 o URI Suffix: http-opportunistic 233 o Change Controller: IETF 235 o Specification Document(s): Section 2.3 of [this specification] 237 o Related Information: 239 4. Security Considerations 241 4.1. Security Indicators 243 User Agents MUST NOT provide any special security indicia when an 244 "http" resource is acquired using TLS. In particular, indicators 245 that might suggest the same level of security as "https" MUST NOT be 246 used (e.g., a "lock device"). 248 4.2. Downgrade Attacks 250 A downgrade attack against the negotiation for TLS is possible. 252 For example, because the "Alt-Svc" header field [RFC7838] likely 253 appears in an unauthenticated and unencrypted channel, it is subject 254 to downgrade by network attackers. In its simplest form, an attacker 255 that wants the connection to remain in the clear need only strip the 256 "Alt-Svc" header field from responses. 258 4.3. Privacy Considerations 260 Cached alternative services can be used to track clients over time; 261 e.g., using a user-specific hostname. Clearing the cache reduces the 262 ability of servers to track clients; therefore clients MUST clear 263 cached alternative service information when clearing other origin- 264 based state (i.e., cookies). 266 4.4. Confusion Regarding Request Scheme 268 HTTP implementations and applications sometimes use ambient signals 269 to determine if a request is for an "https" resource; for example, 270 they might look for TLS on the stack, or a server port number of 443. 272 This might be due to expected limitations in the protocol (the most 273 common HTTP/1.1 request form does not carry an explicit indication of 274 the URI scheme and the resource might have been developed assuming 275 HTTP/1.1), or it may be because how the server and application are 276 implemented (often, they are two separate entities, with a variety of 277 possible interfaces between them). 279 Any security decisions based upon this information could be misled by 280 the deployment of this specification, because it violates the 281 assumption that the use of TLS (or port 443) means that the client is 282 accessing a HTTPS URI, and operating in the security context implied 283 by HTTPS. 285 Therefore, servers need to carefully examine the use of such signals 286 before deploying this specification. 288 4.5. Server Controls 290 This specification requires that a server send both an Alternative 291 Service advertisement and host content in a well-known location to 292 send HTTP requests over TLS. Servers SHOULD take suitable measures 293 to ensure that the content of the well-known resource remains under 294 their control. Likewise, because the Alt-Svc header field is used to 295 describe policies across an entire origin, servers SHOULD NOT permit 296 user content to set or modify the value of this header. 298 5. References 300 5.1. Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 308 DOI 10.17487/RFC2818, May 2000, 309 . 311 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 312 (TLS) Protocol Version 1.2", RFC 5246, 313 DOI 10.17487/RFC5246, August 2008, 314 . 316 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 317 Uniform Resource Identifiers (URIs)", RFC 5785, 318 DOI 10.17487/RFC5785, April 2010, 319 . 321 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 322 DOI 10.17487/RFC6454, December 2011, 323 . 325 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 326 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 327 2014, . 329 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 330 Protocol (HTTP/1.1): Message Syntax and Routing", 331 RFC 7230, DOI 10.17487/RFC7230, June 2014, 332 . 334 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 335 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 336 DOI 10.17487/RFC7232, June 2014, 337 . 339 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 340 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 341 RFC 7234, DOI 10.17487/RFC7234, June 2014, 342 . 344 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 345 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 346 DOI 10.17487/RFC7540, May 2015, 347 . 349 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 350 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 351 April 2016, . 353 5.2. Informative References 355 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 356 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 357 2014, . 359 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 360 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 361 December 2014, . 363 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 364 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 365 2015, . 367 [W3C.CR-mixed-content-20160802] 368 West, M., "Mixed Content", World Wide Web Consortium CR 369 CR-mixed-content-20160802, August 2016, 370 . 372 Appendix A. Acknowledgements 374 Mike Bishop contributed significant text to this document. 376 Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen 377 Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam 378 Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard 379 Barnes for their feedback and suggestions. 381 Authors' Addresses 383 Mark Nottingham 385 Email: mnot@mnot.net 386 URI: https://www.mnot.net/ 388 Martin Thomson 389 Mozilla 391 Email: martin.thomson@gmail.com