idnits 2.17.1 draft-vidya-httpbis-explicit-proxy-ps-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'DANE' on line 283 -- Looks like a reference, but probably isn't: 'RFC2616' on line 289 == Unused Reference: '1' is defined on line 406, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Narayanan 3 Internet-Draft Google 4 Intended status: Informational October 21, 2013 5 Expires: April 24, 2014 7 Explicit Proxying in HTTP - Problem Statement And Goals 8 draft-vidya-httpbis-explicit-proxy-ps-00 10 This document may contain material from IETF Documents or IETF 11 Contributions published or made publicly available before November 12 10, 2008. The person(s) controlling the copyright in some of this 13 material may not have granted the IETF Trust the right to allow 14 modifications of such material outside the IETF Standards Process. 15 Without obtaining an adequate license from the person(s) controlling 16 the copyright in such materials, this document may not be modified 17 outside the IETF Standards Process, and derivative works of it may 18 not be created outside the IETF Standards Process, except to format 19 it for publication as an RFC or to translate it into languages other 20 than English. 22 Abstract 24 This document describes the issues with HTTP proxies for TLS 25 protected traffic and motivates the need for explicit proxying 26 capability in HTTP. It also presents the goals that such a solution 27 would need to satisfy and some example solution directions. 29 Status of This Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 24, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Proxying Needs Today . . . . . . . . . . . . . . . . . . . . 3 62 4. Proxy Configurations Today . . . . . . . . . . . . . . . . . 4 63 5. Problems With Proxies Today . . . . . . . . . . . . . . . . . 5 64 6. Explicit HTTP Proxying . . . . . . . . . . . . . . . . . . . 5 65 6.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1.1. On Users, Intermediaries And Content Providers . . . 6 67 6.1.2. On Today's Practices . . . . . . . . . . . . . . . . 6 68 6.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Potential Solution Directions . . . . . . . . . . . . . . . . 8 70 7.1. Do Nothing . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.2. Signed Policy Per Origin . . . . . . . . . . . . . . . . 8 72 7.3. Explicit Proxy Detection using HTTP/TLS . . . . . . . . . 8 73 7.4. Object Level Security in HTTP . . . . . . . . . . . . . . 9 74 7.5. TLS Origin Cert Exchanges . . . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 Web proxies that are present in the communication path between 84 clients and servers are fairly common practice. There are many 85 reasons one may employ a proxy, but the commonly deployed scenarios 86 today are at odds with client to server privacy. While in almost all 87 cases, some kind of user consent is received to carry traffic through 88 proxies, such consent is fairly vague and the user is often unaware 89 about the extent to which proxies have visibility into their 90 communications. In some cases, such visibility may be construed as 91 an unacceptable violation of privacy. 93 This document describes the types of proxies and the issues with the 94 currently used models. It makes a case for legitimizing the use of 95 proxies while providing sufficient transparency to the endpoints. 96 Towards that end, it also sets goals towards designing such an 97 explicit proxying mechanism for http communication. Note that the 98 scope of this document is limited to HTTPS only - HTTP communication 99 not protected by TLS is out of scope for this discussion. 101 2. Motivation 103 The move to securing http connections is often to provide a 104 confidential channel for exchange of information between a client and 105 server. In the presence of a proxy, a secure channel may perceived 106 to be end-to-end when it is in fact not the case. To fix this, 107 proxies must be visible to the communicating endpoints. However, 108 without an interoperable solution, explicit proxying of connections 109 becomes an issue. The motivations to make proxying explicit include: 111 o Making secure communications possible for users 113 o Allowing endpoints to choose not to communicate in the presence of 114 an intermediary 116 o Ensuring that a proxy is authorized to be in the path 118 o Allowing detection of modified content 120 o Allowing the ability to cache content in intermediate entities 122 3. Proxying Needs Today 124 There are number of reasons proxies have been deployed in networks. 125 Some of these reasons include: 127 o Policy Enforcement 129 Authentication and bandwidth policies may be often enforced using 130 a proxy. This allows the model of having conditional connectivity 131 or limits on connectivity such as may be observed in a hotel or an 132 airport hotspot, among other places. For TLS protected 133 connections, this type of policy enforcement becomes difficult 134 (the connections just fail until the user finds a way to 135 authenticate with the proxy). But, it may be useful to support 136 this using explicit proxying techniques for a better experience. 138 o Caching 140 Very widely used on the Internet, caching proxies allow serving of 141 content from topologically closer sources in order to preserve 142 network resources and improve user experience. 144 o Content Modification 146 Certain networks employ content modifying proxies that generally 147 modify content to improve network and overall user experience. 148 For instance, proxies in mobile networks may need to modify 149 content to change the codec for sake of older devices. However, 150 sometimes, content modification proxies have also been known to 151 make high definition content unavailable - while arguably this may 152 be in the best interest in balancing the overall health of the 153 network (a bad network isn't good for any user), this is also 154 highly debatable. 156 o Content Filtering 158 Content filtering proxies may prevent malware, but may also 159 prevent access to sites that are in violation of the 160 administrative policies. This filtering may be by size, type or 161 subject matter. 163 o Content Inspection 165 Some proxies may be installed with a need to inspect and flag 166 inappropriate content (e.g., in schools). 168 As can be seen, some of the proxies need access to the content, while 169 others do not. 171 4. Proxy Configurations Today 173 Proxies used to be configured manually by having the users specify 174 the proxy information in the browser settings. However, due to the 175 difficulty in effectively implementing this approach (specifically 176 that the user needed to be involved when he/she moved out of the 177 proxy's network), two proxying models have evolved. One is the group 178 configuration policies that are used in enterprises, where a device 179 that is part of an enterprise gets subjected to the enterprise 180 proxying policies by pre configuration. 182 Another is the model of "interception" or "transparent" proxies 183 became widely popular and is also in a fairly large use today. In 184 the "transparent" proxy model, neither endpoint knows about the 185 interception. Transparent proxies can be employed in the presence of 186 TLS (HTTPS) as well, when certificate pinning is disabled. Most 187 deployments end up disabling certificate pinning so that proxying can 188 be accomplished. The client machines are often configured with root 189 certs that will allow it to accept the proxy generated ephemeral 190 certificate for the server. Future configurations of proxies 191 continues to be a problem and explicit mechanisms of configuring 192 proxies may be necessary to motivate the move away from interception 193 proxies. 195 There are also tunneling proxies, where HTTP CONNECT may be used to 196 tunnel the client requests to the server. 198 5. Problems With Proxies Today 200 The use of proxies leads to a number of privacy issues. To 201 summarize: 203 o The user often has no knowledge that their data exchanges are 204 passing through an interception proxy that potentially has 205 visibility to the actual content exchanged. 207 o The server has no knowledge of the presence of the proxy and 208 hence, cannot refuse to serve sensitive content over a proxied 209 connection. 211 o The weakened security model, when certificate pinning is disabled 212 at a general level, allows inspection of content potentially by 213 entities other than legitimate proxies that the user may be 214 willing to give access to. This is especially true in enterprises 215 with a multitude of platforms, devices and browsers, where 216 explicit configuration of proxy certificates is an administrative 217 burden. 219 o The client can no longer authenticate the real server. Hence, the 220 client has no influence on certificate revocation checks and any 221 visible warnings to the user are made infeasible. 223 o Client authentication (and hence mutual authentication) is made 224 infeasible. Any server relying upon mutual authentication to 225 establish a TLS connection cannot work with transparent proxies. 227 o The user has no way of detecting whether content has been modified 228 en route. 230 o The client is susceptible to downgrade attacks, as it cannot do 231 any policy enforcement on versions or algorithms. 233 With privacy becoming more and more important, it is important for us 234 to support solutions that allow awareness of a privacy breach to both 235 users and the servers, when that happens. To this effect, it is 236 important that proxies be explicitly supported and detected. 238 6. Explicit HTTP Proxying 239 The problems illustrated in this document call for explicit knowledge 240 of on-path proxies to the user and the content provider. The key 241 assumptions and goals driving this target are stated below. 243 6.1. Assumptions 245 6.1.1. On Users, Intermediaries And Content Providers 247 o Users configure proxies and forget about the configuration. 249 o Users have limited control over provider installed certificates. 251 * Often, the user's only choice is to not sign up for service at 252 all. 254 o Users may not wish to have some or any of their communications 255 intercepted, even when they are on a network for which they 256 previously configured a proxy. 258 o Intermediaries have various legitimate reasons for wanting to 259 inspect traffic: 261 * Cache content 263 * Implement network traffic policies (e.g. legal compliance, 264 malware detection, etc) 266 o Content providers may not wish to serve certain content in 267 anything less than an end-to-end secure fashion. 269 6.1.2. On Today's Practices 271 o Many networks seem to leave the traffic on port 443 untouched and 272 unblocked today, likely as a result of both the importance of the 273 data and the relative rarity of communications using TLS. It is 274 unclear how this might change as TLS protected traffic increases, 275 if we continued to not have a solution for explicit proxying. 277 o Entities which need to inspect traffic on port 443 today are 278 forced to either block port 443 or to deploy an intercepting proxy 279 and install root certs on all devices which may use the network. 280 In the latter case, the deployed proxy impersonates both the 281 content-provider to the user-agent, and the user-agent to the 282 content-provider. Though there is work to allow users to detect 283 these situations [DANE], support is not widespread. 285 o Many, if not most, mobile devices using cellular networks use 286 proxies and several of them act as transforming proxies. 288 o Users and sites have only one mechanism for specifying point-to- 289 point security policy for HTTP [RFC2616], which is the scheme of 290 the URI identifying any particular resource. 292 6.2. Goals 294 These are the goals of a solution aimed at making proxying explicit 295 in HTTP. 297 o In the presence of a proxy, users' communications SHOULD at least 298 use a channel that is point-to-point encrypted. 300 o Users MUST be able to opt-out of communicating sensitive 301 information over a channel which is not end-to-end private. 303 o Content-providers MAY serve certain content only in an end-to-end 304 confidential fashion. 306 o Interception proxies MUST be precluded from intercepting secure 307 communications between the user and the content-provider. 309 o User-agents and servers MUST know when a transforming proxy is 310 interposed in the communications channel. 312 o User-agents MUST be able to detect when content requested with an 313 https scheme has been modified by any intermediate entity. 315 o Entities other than the server or user-agent SHOULD still be able 316 to provide caching services. 318 o User agents MUST be able to verify that the content is in fact 319 served by the content provider. 321 o A set of signaling semantics should exist which allows the 322 content-provider and the user to have the appropriate level of 323 security or privacy signaled per resource. 325 o Ideally, HTTP URI semantics SHOULD NOT change, but if it does, it 326 must remain backwards-compatible. 328 o Configuration and deployment of proxies should be as easy as 329 currently used solutions. 331 o Introduction of explicit proxying MUST NOT require a flag day 332 upgrade - in other words, it should work with existing client and 333 content provider implementations during the transition. 335 7. Potential Solution Directions 337 There are several potential directions this work can take, some of 338 which are clearly undesirable and some that are more viable. This 339 section is not intended for an exhaustive description of each 340 solution - rather, it is aimed at serving as a starting point for 341 discussions. Note that more than one of these directions may need to 342 be adopted and brought together for a complete solution - so, each 343 section here is not intended to be standalone and complete. 345 7.1. Do Nothing 347 This is a scenario that continues to support interception proxies in 348 current modes. The fundamental premise of this document is based on 349 the fact that this is bad. 351 7.2. Signed Policy Per Origin 353 RFC6454 specifies a method by which there can be a signed policy per 354 origin. However, such coarse granularity of providing a policy for 355 an entire domain is often not useful and hence, this is rarely used 356 in practice. 358 7.3. Explicit Proxy Detection using HTTP/TLS 360 Means of: 362 o Explicit signaling of presence of proxy from user agent to server. 364 o Signaling to indicate user preference for end-to-end secure 365 communication 367 o Signaling to indicate content unavailability via proxies 369 o Verification of proxy identity to detect untrusted proxies 371 o Serving interstitial pages to manage portals that enforce 372 bandwidth, connectivity times, etc. 374 The above can be accomplished in a variety of ways, including HTTP/ 375 TLS error codes, HTTP2.0 proxy signaling semantics and HTTP/TLS 376 exchange of proxy identities. 378 7.4. Object Level Security in HTTP 380 The ability to detect modified content is needed. Specifically: 382 o Object level integrity protection of content by content provider 384 o Object level encryption by content provider (optionally) 386 7.5. TLS Origin Cert Exchanges 388 The ability to exchange the true certificate chain of the server in 389 TLS exchanges so that clients can make better decisions about 390 servers. 392 8. Security Considerations 394 TBD 396 9. IANA Considerations 398 TBD 400 10. Acknowledgments 402 List of names here - TBD 404 11. Normative References 406 [1] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 Author's Address 411 Vidya Narayanan 412 Google 413 1600 Amphitheatre Pkwy 414 Mountain View, CA 415 USA 417 Email: vn@google.com