idnits 2.17.1 draft-rpeon-httpbis-exproxy-00.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 8, 2012) is 4333 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Peon 3 Internet-Draft Google, Inc 4 Intended status: Informational June 8, 2012 5 Expires: December 10, 2012 7 Explicit Proxies for HTTP/2.0 8 draft-rpeon-httpbis-exproxy-00 10 Abstract 12 This document describes a method for connecting to a proxy via a 13 secure channel, allowing, disallowing, and detecting any transforms 14 that the proxy may perform, and allowing the proxy to connect via 15 secure channel to another site on the user's behalf. 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 10, 2012. 34 Copyright Notice 36 Copyright (c) 2012 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. What it looks like today . . . . . . . . . . . . . . . . . . . 4 54 4. Where we would like to be . . . . . . . . . . . . . . . . . . 4 55 5. Problems with end-to-end privacy? . . . . . . . . . . . . . . 5 56 6. Proposed Solution: Use Explicit Proxies . . . . . . . . . . . 6 57 7. Mixed trust mode . . . . . . . . . . . . . . . . . . . . . . . 9 58 8. Rejected Alternatives . . . . . . . . . . . . . . . . . . . . 9 59 9. Impact on other areas of the protocol . . . . . . . . . . . . 10 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 11. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11 62 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 63 13. Normative References . . . . . . . . . . . . . . . . . . . . . 11 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Overview 68 It has been proposed that a secure channel be utilized for all 69 HTTP/2.0 traffic coming from users using browsers. As a first order 70 effect, this would obviously improve security, but it could have the 71 second order effect of banishing all communication over any secure 72 channel for lack of a mechanism to allow the owners of the network to 73 apply desired policies to the messaging going on within it. Another 74 second order effect could be user selection away from this protocol 75 if it doesn't meet their performance expectations. This document 76 proposes mechanisms intended to ameleoriate these issues. This 77 document does not exhaustively cover configuring a proxy in a 78 browser. 80 2. Definitions 82 user-agent: The program or device which a human interacts with 83 directly and which typically initiates the transport layer 84 connection or session 86 client: Synonym for user-agent 88 user: The human using the user-agent 90 server: The computer or device which typically accepts a 91 connection and serves data 93 content-provider: The server to which the user-agent ultimately 94 wishes to speak 96 configured-proxy: The entity to which the user-agent is 97 explicitly configured to speak and which the user-agent expects 98 will connect to the content-provider on the user-agent's behalf 100 trusted-proxy: A configured-proxy to which the user-agent has 101 been configured to give decryption key material 103 caching-proxy: A configured-proxy to which the user-agent has 104 NOT been conigured to give decryption key material 106 end-to-end: From the user-agent to the content-provider 108 point-to-point: Between any two pairs of adjacent entities. If 109 the entities are user-agent and content-provider, this is also 110 end-to-end, but for any other pair of entities, it is only 111 point-to-point. 113 secure-hash: A cryptographic hash resistent to preimage and 114 collision attacks, whether as part of a hash tree (e.g. Merkle 115 tree), hash list, etc. 117 3. What it looks like today 119 Today: 121 Using TLS [RFC5246] over port 443 is often the exception rather 122 than the rule. 124 Many users use radio-based devices which transmit data 125 effectively in the clear, allowing their credentials and 126 identity to be stolen. 128 Many networks seem to leave the traffic on port 443 untouched 129 and unblocked, likely as a result of both the importance of the 130 data and the relative rarity of communications using TLS. 132 Entities which need to inspect traffic on port 443 today are 133 forced to either block port 443 or to deploy an intercepting 134 proxy and install root certs on all devices which may use the 135 network. In the latter case, the deployed proxy impersonates 136 both the content-provider to the user-agent, and the user-agent 137 to the content-provider. Though there is work to allow users 138 to detect these situations [DANE], support is not widespread. 140 Users are likely to see both beneficial and detrimental 141 behavior as a result of transparent proxies. 143 Many, if not most, mobile devices using cellular networks use 144 proxies 146 Users and sites have only one mechanism for specifying point- 147 to-point security policy for HTTP [RFC2616], which is the 148 scheme of the URI identifying any particular resource. 150 4. Where we would like to be 152 In the future: 154 A user's communications should use a channel which is point-to- 155 point secure by default for all communications. 157 Users should be able to opt-out of communicating sensitive 158 information over a channel which is not end-to-end private. 160 Only proxies which are known to and configured by the user 161 should be allowed to intercept communications between the user 162 and the content-provider. 164 User-agents and servers should know when a proxy is interposed 165 in the communications channel. 167 User-agents should be able to detect when content requested 168 with an https scheme has been modified by a proxy. 170 Caching should still be a service which can be provided by 171 entities other than the server or user-agent. 173 Caches, when allowed, should be exceedingly difficult to 174 poison. 176 A set of signaling semantics should exist which allows the 177 content-provider and the user to have the appropriate level of 178 security or privacy signaled per resource. 180 5. Problems with end-to-end privacy? 182 Entities may wish to have a proxy interposed in communication for a 183 number of reasons including (but not limited to): 185 Looking for and blocking malware 187 Filtering for content by size, type, or subject matter 189 Provide caching services so as to improve the user experience 191 Unfortunately, if communication is to be done in majority or 192 completely using end-to-end privacy, then none of the above use-cases 193 are possible without installing root certs on users' devices. There 194 are several possible consequences for having only end-to-end privacy: 196 It may become common for entites to install root certs on 197 users' devices, and users may become accustomed to doing this, 198 even on their personaly owned devices. This could cause a 199 breach of all trust-chains, and could reduce aggregate 200 security. 202 Entities which own networks may decide to block port 443, else 203 face noncompliance of policy or law. This would obviously 204 reduce aggregate security. 206 Clients at the end of long, thin pipes may decide that speed 207 matters more than security, and disable use of the new, secure 208 protocol. This would also obviously decrease aggregate 209 security. 211 The assumptions and potential consequences in this section should be 212 carefully deliberated. 214 6. Proposed Solution: Use Explicit Proxies 216 Since failing to allow for some kind of interception technique may 217 reduce aggregate security, it is suggested we design for and allow 218 explicit proxies which may examine contents as they pass by. This is 219 not something to be done lightly, and so we must be careful to allow 220 the user-agent to select an appropriate level of trust. We must also 221 provide for a fallback in cases where the proxy or server does not 222 adhere to this proposal so that in the worst case we get what we have 223 today. 225 For the purpose of this document, it is assumed that the user locates 226 a piece of paper upon a wall and reads it, typing these proxy 227 settings into a configuration field for their user-agent. This is 228 obviously not the only possible configuration mechanism, but it may, 229 sadly, be the most secure. It is assumed that alternate distribution 230 techniques may be discussed. 232 For HTTPS schemes, if a proxy is configured: 234 The user-agent MUST indicate to the content-provider that it is 235 going through a proxy via the tunnel as the first bit of 236 information presented. 238 If a link in an HTML [RFC2854] document includes a secure-hash 239 of the data, e.g. , and the link was provided in a secure 241 manner (e.g. over an end-to-end communications channel that 242 includes integrity checks), then the user-agent MAY request the 243 indicated resource directly from the explicitly configured 244 proxy. The configured proxy MAY serve the data from its cache, 245 but it MUST NOT modify the content in any way. The user-agent 246 MUST reject any received data if is unable to verify its 247 integrity or if the secure-hash does not match the hash over 248 the provided data. The presence of the secure-hash is, itself, 249 signals that the content may be fetched in a non-private 250 channel. RFC6249 [RFC6249] provides some descriptions of 251 cryptographic-hash implementations. 253 The above need not be the only mechanism for providing signals 254 that data can be served via a cache, but the data MUST always 255 be verifiably unmodified. As an example, other mechanisms for 256 providing secure-hashes could be: 258 The URI syntax [RFC3986] could be modified to include a 259 hash of the contents. 261 A signed manifest may be sent which includes one or more 262 secure-hashes of byte-ranges of the data, either fetched 263 via a separate resource or sent in-band. The signature, 264 would, of course, have to be validated before the secure- 265 hashes were to be trusted, and before any requests were 266 sent in a non end-to-end private channel. RFC6249 267 [RFC6249] provides some descriptions of such mechanisms. 268 Bittorrent provides another example [BITTORRENT]. 270 Within the TLS Tunnel, frames may be sent describing the 271 secure-hash of a byte-range of the data, by request from 272 the user-agent. Multiple secure-hashes may be returned 273 if the byte-range mapping on the server differs from that 274 requested by the client. This alternative is most 275 interesting for its ability to describe dynamically 276 generated data (such as live video) safely and in a way 277 that can be consumed by the client in a closer-to-real- 278 time manner, and for supporting range-requests. If 279 implemented in a protocol similar to SPDY [SPDY], this 280 could be accomplished with HEADER frames or equivalent. 282 If the user agent has no means of verifying the data is 283 unmodified, the user-agent either MUST tunnel through the proxy 284 by doing a CONNECT with a TLS tunnel, or the user-agent MUST 285 reuse a previously-created tunnel offering the same security. 286 If the proxy refuses this communication the user-agent MUST 287 attempt a connection directly to the content-provider, avoiding 288 the proxy. 290 We're proposing that user-agents allow for two levels of security for 291 any proxy: 293 Trusted Proxy - all data sent and received is inspected by the 294 proxy 295 Caching Proxy - only data which could be served from the cache is 296 inspected by the proxy 298 It is also possible for a user-agent to use a proxy in both 299 configured and trusted-proxy modes. This document does not include 300 mechanisms for signaling this. 302 In the case where the proxy connects to the content-provider using a 303 secure, multiplexed connection, the following diagram and description 304 would apply: 306 Anne = the client or user-agent 307 Bob = point-to-point secure multiplexed connection from Anne<->Chris 308 Chris = the proxy 309 Don = point-to-point secure multiplexed connection from Chris<->Ed 310 Ed = the content-provider 312 Client Proxy Content-provider 313 | | | 314 | /==spdy-connection=Bob==\ | /==spdy-connection=Don==\ | 315 Anne --connect-stream-- Chris --connect-stream-- Ed 316 \=======================/ \=======================/ 318 In the case where the user-agent has been configured with Chris as a 319 trusted-proxy, either Anne's connect-stream MUST use either a null- 320 cipher, or Anne MUST provide the decryption key material to Chris 321 immediately after tunnel establishment, and before any data traverses 322 the tunnel. 323 In the case where the user-agent has been configured with Chris as a 324 caching proxy, Anne's connect-stream SHOULD NOT use the null cipher, 325 and Anne SHOULD NOT provide the decryption key material to Chris. 327 In *all* cases, the user-agent must indicate that it is traversing a 328 proxy within the connect-tunnel, and indicate whether the proxy is a 329 trusted-proxy or caching-proxy. 331 In the case where the proxy cannot use a secure, multiplexed 332 connection when connecting to the content-provider, the following 333 diagram and description would apply. It is hoped that this case will 334 never be selected as a spec-compliant implementation for forward 335 proxies as it offers significantly less scalability than the option 336 proposed above. 338 Anne = the client or user-agent 339 Bob = point-to-point secure multiplexed connection from Anne<->Chris 340 Chris = the proxy 341 Ed = the content-provider 343 Client Proxy Content-provider 344 | | | 345 | /==spdy-connection=Bob==\ | | 346 Anne --connect-stream-- Chris <--connect-stream--> Ed 347 \=======================/ 349 In both trusted-proxy and caching-proxy cases, Anne must select a 350 non-null cipher for use in the tunnel. In both the trusted-proxy and 351 caching-proxy cases, the proxy simply forwards the tunnel's bytes to 352 Ed and vice-versa. In the case where the user-agent has been 353 configured with Chris as a trusted-proxy, Anne MUST provide the 354 decryption key material to Chris immediately after tunnel 355 establishment, and before any data is sent along the tunnel. 356 In the case where the user-agent has been configured with Chris as a 357 caching-proxy, Anne SHOULD NOT provide the decryption key material to 358 Chris. If Anne selected a null-cipher in this case, Chris MUST 359 reject the connection, forcing Anne to attempt to fallback on a 360 separate connection. 362 In *all* cases, the user-agent must indicate that it is traversing a 363 proxy within the connect-tunnel, and indicate whether the proxy is a 364 trusted-proxy or caching-proxy. 366 7. Mixed trust mode 368 If a signaling mechanism is created which reliably indicates that 369 some data be used in caching-proxy mode, where other data be 370 retrieved in trusted-proxy mode, the user-agent MAY create two 371 tunnels (one for each mode). A mechanism to signal this is not 372 included in this document. A single tunnel MUST NOT be used, as it 373 is impossible to both allow inspection and privacy simultaneously 374 using mechanisms as proposed here. 376 8. Rejected Alternatives 377 Do nothing - 378 This assumes that port 443 won't be blocked, which is contrary 379 to the assumptions in this document. 381 100% trust of the proxy at all times - 382 Hopefully it is obvious why this is bad. 384 Signed policy per response - 385 With this mechanism, the user-agent would expect a piece of 386 signed metadata with each message from the content-provider. 387 This has the disadvantage of being fairly chatty, but the worst 388 part is the requirement to be shuttling around private-key 389 material on the part of the content-provider. This material 390 should be held closely; anything requiring its constant use 391 will likely undermine its secrecy. It is also expensive to be 392 signing things all the time... 394 Signed policy per domain or origin [RFC6454] - 395 With this mechanism, the user-agent would expect a piece of 396 signed metadata with the first response to a request. The one- 397 domain-one-policy seems too restrictive for today's site 398 compositions, and doesn't match HTTP's current caching 399 semantics. 401 9. Impact on other areas of the protocol 403 If we assume that we'll see widespread 'Caching Proxy' deployment, 404 and we assume that the proxies will multiplex multiple incoming 405 streams over fewer outgoing connections, then we may lose some of the 406 current benefits of header compression, and must worry about endpoint 407 per-connection stream limits. 409 If the mechanisms in this document are widely used, mechanisms which 410 reduce the number of RTTs for the TLS handshake phase(s) including 411 anything which allows for fast, efficient, safe resumption would be 412 of high importance. 414 10. Security Considerations 416 Everything in this document should be carefully scrutinized as 417 everything in this document impacts security. 419 A particular worry is the 'Trusted Proxy' mode. Does its presence 420 undermine end-to-end security so much that the benefit of the 421 proposal is moot? In particular, would users as a whole or in a 422 significant part of the population be inclined to ignore (hopefully 423 dire) warnings about using 'Trusted Proxy' mode when they didn't own 424 the proxy? 426 11. Requirements Notation 428 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 429 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 430 document are to be interpreted as described in [RFC2119]. 432 12. Acknowledgements 434 [RFC6454]; 436 13. Normative References 438 [BITTORRENT] 439 Cohen, B., "The BitTorrent Protocol Specification", 440 BITTORRENT 11031, February 2008, 441 . 443 [DANE] Hoffman, P. and J. Schlyter, "DANE", April 2012, 444 . 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 450 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 451 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 453 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 454 Type", RFC 2854, June 2000. 456 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 457 Resource Identifier (URI): Generic Syntax", STD 66, 458 RFC 3986, January 2005. 460 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 461 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 463 [RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P., and H. 464 Nordstrom, "Metalink/HTTP: Mirrors and Hashes", RFC 6249, 465 June 2011. 467 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 468 December 2011. 470 [SPDY] Belshe, M. and R. Peon, "SPDY PROTOCOL", 471 . 473 Author's Address 475 Roberto Peon 476 Google, Inc 478 Email: fenix@google.com