idnits 2.17.1 draft-ietf-httpbis-http2-encryption-08.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 (October 31, 2016) is 2726 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7469' is defined on line 362, 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: May 4, 2017 Mozilla 6 October 31, 2016 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-08 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 May 4, 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 . . . . . . . . . . . . . . 4 67 2.3. The "http-opportunistic" well-known URI . . . . . . . . . 5 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 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], or "http/1.1" [RFC7301]. Note that 129 HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of 130 [RFC7230]). 132 A client that receives such an advertisement MAY make future requests 133 intended for the associated origin ([RFC6454]) to the identified 134 service (as specified by [RFC7838]), provided that the alternative 135 service opts in as described in Section 2.1. 137 A client that places the importance of protection against passive 138 attacks over performance might choose to withhold requests until an 139 encrypted connection is available. However, if such a connection 140 cannot be successfully established, the client can resume its use of 141 the cleartext connection. 143 A client can also explicitly probe for an alternative service 144 advertisement by sending a request that bears little or no sensitive 145 information, such as one with the OPTIONS method. Likewise, clients 146 with existing alternative services information could make such a 147 request before they expire, in order minimize the delays that might 148 be incurred. 150 Client certificates are not meaningful for URLs with the "http" 151 scheme, and therefore clients creating new TLS connections to 152 alternative services for the purposes of this specification MUST NOT 153 present them. Connections that use client certificates for other 154 reasons MAY be reused, though client certificates MUST NOT affect the 155 responses to requests for "http" resources. 157 2.1. Alternative Server Opt-In 159 It is possible that the server might become confused about whether 160 requests' URLs have a "http" or "https" scheme, for various reasons; 161 see Section 4.4. To ensure that the alternative service has opted 162 into serving "http" URLs over TLS, clients are required to perform 163 additional checks before directing "http" requests to it. 165 Clients MUST NOT send "http" requests over a secured connection, 166 unless the chosen alternative service presents a certificate that is 167 valid for the origin - as per [RFC2818] (this also establishes 168 "reasonable assurances" for the purposes of {RFC7838}}) - and they 169 have obtained a valid http-opportunistic response for an origin (as 170 per Section 2.3). 172 For example, assuming the following request is made over a TLS 173 connection that is successfully authenticated for those origins, the 174 following request/response pair would allow requests for the origins 175 "http://www.example.com" or "http://example.com" to be sent using a 176 secured connection: 178 GET http://example.com/.well-known/http-opportunistic HTTP/1.1 179 Host: example.com 181 HTTP/1.1 200 OK 182 Content-Type: application/json 183 Connection: close 185 [ "http://www.example.com", "http://example.com" ] 187 2.2. Interaction with "https" URIs 189 When using alternative services, requests for resources identified by 190 both "http" and "https" URIs might use the same connection, because 191 HTTP/2 permits requests for multiple origins on the same connection. 193 Because of the potential for server confusion about the scheme of 194 requests (see Section 4.4), clients MUST NOT send "http" requests on 195 a connection prior to successfully retrieving a valid http- 196 opportunistic resource that contains the origin (see Section 2.3). 197 The primary purpose of this check is to provide a client with some 198 assurance that a server understands this specification and has taken 199 steps to avoid being confused about request scheme. 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 3. IANA Considerations 225 This specification registers a Well-Known URI [RFC5785]: 227 o URI Suffix: http-opportunistic 229 o Change Controller: IETF 231 o Specification Document(s): Section 2.3 of [this specification] 233 o Related Information: 235 4. Security Considerations 236 4.1. Security Indicators 238 User Agents MUST NOT provide any special security indicia when an 239 "http" resource is acquired using TLS. In particular, indicators 240 that might suggest the same level of security as "https" MUST NOT be 241 used (e.g., a "lock device"). 243 4.2. Downgrade Attacks 245 A downgrade attack against the negotiation for TLS is possible. 247 For example, because the "Alt-Svc" header field [RFC7838] likely 248 appears in an unauthenticated and unencrypted channel, it is subject 249 to downgrade by network attackers. In its simplest form, an attacker 250 that wants the connection to remain in the clear need only strip the 251 "Alt-Svc" header field from responses. 253 4.3. Privacy Considerations 255 Cached alternative services can be used to track clients over time; 256 e.g., using a user-specific hostname. Clearing the cache reduces the 257 ability of servers to track clients; therefore clients MUST clear 258 cached alternative service information when clearing other origin- 259 based state (i.e., cookies). 261 4.4. Confusion Regarding Request Scheme 263 HTTP implementations and applications sometimes use ambient signals 264 to determine if a request is for an "https" resource; for example, 265 they might look for TLS on the stack, or a server port number of 443. 267 This might be due to limitations in the protocol (the most common 268 HTTP/1.1 request form does not carry an explicit indication of the 269 URI scheme), or it may be because how the server and application are 270 implemented (often, they are two separate entities, with a variety of 271 possible interfaces between them). 273 Any security decisions based upon this information could be misled by 274 the deployment of this specification, because it violates the 275 assumption that the use of TLS (or port 443) means that the client is 276 accessing a HTTPS URI, and operating in the security context implied 277 by HTTPS. 279 Therefore, servers need to carefully examine the use of such signals 280 before deploying this specification. 282 4.5. Server Controls 284 This specification requires that a server send both an Alternative 285 Service advertisement and host content in a well-known location to 286 send HTTP requests over TLS. Servers SHOULD take suitable measures 287 to ensure that the content of the well-known resource remains under 288 their control. Likewise, because the Alt-Svc header field is used to 289 describe policies across an entire origin, servers SHOULD NOT permit 290 user content to set or modify the value of this header. 292 5. References 294 5.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 302 DOI 10.17487/RFC2818, May 2000, 303 . 305 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 306 (TLS) Protocol Version 1.2", RFC 5246, 307 DOI 10.17487/RFC5246, August 2008, 308 . 310 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 311 Uniform Resource Identifiers (URIs)", RFC 5785, 312 DOI 10.17487/RFC5785, April 2010, 313 . 315 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 316 DOI 10.17487/RFC6454, December 2011, 317 . 319 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 320 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 321 2014, . 323 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 324 Protocol (HTTP/1.1): Message Syntax and Routing", 325 RFC 7230, DOI 10.17487/RFC7230, June 2014, 326 . 328 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 329 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 330 DOI 10.17487/RFC7232, June 2014, 331 . 333 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 334 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 335 RFC 7234, DOI 10.17487/RFC7234, June 2014, 336 . 338 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 339 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 340 DOI 10.17487/RFC7540, May 2015, 341 . 343 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 344 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 345 April 2016, . 347 5.2. Informative References 349 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 350 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 351 2014, . 353 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 354 "Transport Layer Security (TLS) Application-Layer Protocol 355 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 356 July 2014, . 358 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 359 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 360 December 2014, . 362 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 363 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 364 2015, . 366 [W3C.CR-mixed-content-20160802] 367 West, M., "Mixed Content", World Wide Web Consortium CR 368 CR-mixed-content-20160802, August 2016, 369 . 371 Appendix A. Acknowledgements 373 Mike Bishop contributed significant text to this document. 375 Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen 376 Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam 377 Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard 378 Barnes for their feedback and suggestions. 380 Authors' Addresses 382 Mark Nottingham 384 Email: mnot@mnot.net 385 URI: https://www.mnot.net/ 387 Martin Thomson 388 Mozilla 390 Email: martin.thomson@gmail.com