idnits 2.17.1 draft-ietf-httpbis-http2-encryption-07.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 4, 2016) is 2754 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '443' on line 190 -- Looks like a reference, but probably isn't: '8000' on line 190 == Unused Reference: 'RFC7469' is defined on line 372, 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 (==), 3 comments (--). 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: April 7, 2017 Mozilla 6 October 4, 2016 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-07 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 April 7, 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 . . . . . . . . . . . 7 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]. 130 A client that receives such an advertisement MAY make future requests 131 intended for the associated origin ([RFC6454]) to the identified 132 service (as specified by [RFC7838]), provided that the alternative 133 service opts in as described in Section 2.1. 135 A client that places the importance of protection against passive 136 attacks over performance might choose to withhold requests until an 137 encrypted connection is available. However, if such a connection 138 cannot be successfully established, the client can resume its use of 139 the cleartext connection. 141 A client can also explicitly probe for an alternative service 142 advertisement by sending a request that bears little or no sensitive 143 information, such as one with the OPTIONS method. Likewise, clients 144 with existing alternative services information could make such a 145 request before they expire, in order minimize the delays that might 146 be incurred. 148 Client certificates are not meaningful for URLs with the "http" 149 scheme, and therefore clients creating new TLS connections to 150 alternative services for the purposes of this specification MUST NOT 151 present them. Established connections with client certificates MAY 152 be reused, however. 154 2.1. Alternative Server Opt-In 156 It is possible that the server might become confused about whether 157 requests' URLs have a "http" or "https" scheme, for various reasons; 158 see Section 4.4. To ensure that the alternative service has opted 159 into serving "http" URLs over TLS, clients are required to perform 160 additional checks before directing "http" requests to it. 162 Clients MUST NOT send "http" requests over a connection with the "h2" 163 protocol identifier, unless they have obtained a valid http- 164 opportunistic response for an origin (as per Section 2.3), and: 166 o 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 170 o The origin object of the http-opportunistic response has a `tls- 171 ports' member, whose value is an array of numbers, one of which 172 matches the port of the alternative service in question, and 174 o The chosen alternative service returns the same representation as 175 the origin did for the http-opportunistic resource. 177 For example, this request/response pair would allow reqeusts for the 178 origin "http://www.example.com" to be sent to an alternative service 179 on port 443 or 8000 of the host "www.example.com": 181 GET /.well-known/http-opportunistic HTTP/1.1 182 Host: www.example.com 184 HTTP/1.1 200 OK 185 Content-Type: application/json 186 Connection: close 188 { 189 "http://www.example.com": { 190 "tls-ports": [443, 8000], 191 "lifetime": 2592000 192 } 193 } 195 2.2. Interaction with "https" URIs 197 When using alternative services, requests for resources identified by 198 both "http" and "https" URIs might use the same connection, because 199 HTTP/2 permits requests for multiple origins on the same connection. 201 Because of the risk of server confusion about individual requests' 202 schemes (see Section 4.4), clients MUST NOT send "http" requests on a 203 connection that has previously been used for "https" requests, unless 204 the http-opportunistic origin object Section 2.3 fetched over that 205 connection has a "mixed-scheme" member whose value is "true". 207 2.3. The "http-opportunistic" well-known URI 209 This specification defines the "http-opportunistic" well-known URI 210 [RFC5785]. A client is said to have a valid http-opportunistic 211 response for a given origin when: 213 o The client has obtained a 200 (OK) response for the well-known URI 214 from the origin, and it is fresh [RFC7234] (potentially through 215 revalidation [RFC7232]), and 217 o That response has the media type "application/json", and 219 o That response's payload, when parsed as JSON [RFC7159], contains 220 an object as the root, and 222 o The root object contains a member whose name is a case-insensitive 223 character-for-character match for the origin in question, 224 serialised into Unicode as per Section 6.1 of [RFC6454], and whose 225 value is an object (hereafter, the "origin object"), 227 o The origin object has a "lifetime" member, whose value is a number 228 indicating the number of seconds which the origin object is valid 229 for (hereafter, the "origin object lifetime"), and 231 o The origin object lifetime is greater than the "current_age" (as 232 per [RFC7234], Section 4.2.3). 234 Note that origin object lifetime might differ from the freshness 235 lifetime of the response. 237 3. IANA Considerations 239 This specification registers a Well-Known URI [RFC5785]: 241 o URI Suffix: http-opportunistic 243 o Change Controller: IETF 245 o Specification Document(s): Section 2.3 of [this specification] 247 o Related Information: 249 4. Security Considerations 251 4.1. Security Indicators 253 User Agents MUST NOT provide any special security indicia when an 254 "http" resource is acquired using TLS. In particular, indicators 255 that might suggest the same level of security as "https" MUST NOT be 256 used (e.g., a "lock device"). 258 4.2. Downgrade Attacks 260 A downgrade attack against the negotiation for TLS is possible. 262 For example, because the "Alt-Svc" header field [RFC7838] likely 263 appears in an unauthenticated and unencrypted channel, it is subject 264 to downgrade by network attackers. In its simplest form, an attacker 265 that wants the connection to remain in the clear need only strip the 266 "Alt-Svc" header field from responses. 268 4.3. Privacy Considerations 270 Cached alternative services can be used to track clients over time; 271 e.g., using a user-specific hostname. Clearing the cache reduces the 272 ability of servers to track clients; therefore clients MUST clear 273 cached alternative service information when clearing other origin- 274 based state (i.e., cookies). 276 4.4. Confusion Regarding Request Scheme 278 HTTP implementations and applications sometimes use ambient signals 279 to determine if a request is for an "https" resource; for example, 280 they might look for TLS on the stack, or a server port number of 443. 282 This might be due to limitations in the protocol (the most common 283 HTTP/1.1 request form does not carry an explicit indication of the 284 URI scheme), or it may be because how the server and application are 285 implemented (often, they are two separate entities, with a variety of 286 possible interfaces between them). 288 Any security decisions based upon this information could be misled by 289 the deployment of this specification, because it violates the 290 assumption that the use of TLS (or port 443) means that the client is 291 accessing a HTTPS URI, and operating in the security context implied 292 by HTTPS. 294 Therefore, servers need to carefully examine the use of such signals 295 before deploying this specification. 297 4.5. Server Controls 299 This specification requires that a server send both an Alternative 300 Service advertisement and host content in a well-known location to 301 send HTTP requests over TLS. Servers SHOULD take suitable measures 302 to ensure that the content of the well-known resource remains under 303 their control. Likewise, because the Alt-Svc header field is used to 304 describe policies across an entire origin, servers SHOULD NOT permit 305 user content to set or modify the value of this header. 307 5. References 309 5.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 317 DOI 10.17487/RFC2818, May 2000, 318 . 320 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 321 (TLS) Protocol Version 1.2", RFC 5246, 322 DOI 10.17487/RFC5246, August 2008, 323 . 325 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 326 Uniform Resource Identifiers (URIs)", RFC 5785, 327 DOI 10.17487/RFC5785, April 2010, 328 . 330 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 331 DOI 10.17487/RFC6454, December 2011, 332 . 334 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 335 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 336 2014, . 338 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 339 Protocol (HTTP/1.1): Message Syntax and Routing", 340 RFC 7230, DOI 10.17487/RFC7230, June 2014, 341 . 343 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 344 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 345 DOI 10.17487/RFC7232, June 2014, 346 . 348 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 349 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 350 RFC 7234, DOI 10.17487/RFC7234, June 2014, 351 . 353 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 354 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 355 DOI 10.17487/RFC7540, May 2015, 356 . 358 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 359 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 360 April 2016, . 362 5.2. Informative References 364 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 365 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 366 2014, . 368 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 369 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 370 December 2014, . 372 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 373 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 374 2015, . 376 [W3C.CR-mixed-content-20160802] 377 West, M., "Mixed Content", World Wide Web Consortium CR 378 CR-mixed-content-20160802, August 2016, 379 . 381 Appendix A. Acknowledgements 383 Mike Bishop contributed significant text to this document. 385 Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen 386 Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam 387 Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard 388 Barnes for their feedback and suggestions. 390 Authors' Addresses 392 Mark Nottingham 394 Email: mnot@mnot.net 395 URI: https://www.mnot.net/ 397 Martin Thomson 398 Mozilla 400 Email: martin.thomson@gmail.com