idnits 2.17.1 draft-reschke-objsec-01.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 (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 467 -- Looks like a reference, but probably isn't: '2' on line 463 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Druta 3 Internet-Draft AT&T 4 Intended status: Standards Track T. Fossati 5 Expires: April 30, 2015 Alcatel-Lucent 6 M. Ihlar 7 Ericsson 8 G. Klas 9 Vodafone 10 D. Lopez 11 Telefonica I+D 12 J. Reschke, Ed. 13 greenbytes 14 October 27, 2014 16 A Rationale for Fine-grained Intermediary-aware End-to-End Protocols 17 draft-reschke-objsec-01 19 Abstract 21 A tremendous growth in different uses of the Internet has let to a 22 growing need to protect data sent over public networks, including 23 data sent via http. Use of end-to-end TLS for the majority of 24 traffic looks at first a most feasible response. However, the web 25 architecture has become more sophisticated and as it has now gone 26 beyond the simple client-server model, the end-to-end used of TLS is 27 increasingly showing its downside. The end-to-end use of TLS 28 excludes the use of beneficial intermediaries such as use of caches 29 or proxies that provide instrumental services. Then need for greater 30 privacy seems to collide with the equally growing desire for better 31 end-to-end performance and user experience. As an example, the use 32 of HTTP/TLS often appears to maximise the benefit for the combination 33 of both. 35 This document describes the above dichotomy and lays out a number of 36 objectives of what can ideally be achieved, namely catering for 37 sufficient security and privacy whilst providing users with the 38 opportunity to make use of intermediaries' services where considered 39 beneficial. This document introduces a number of potential solutions 40 towards use of suitable protocol mechanisms and data formats. End- 41 to-end protocols which are aware of intermediaries should enable 42 users and/or content providers to exercise fine-grained control over 43 what intermediaries should be able to do and what exposure to data or 44 metadata they shall be permitted to get. The document then 45 highlights anticipated benefits to key stakeholders such as users, 46 content providers and intermediaries. As elements such as object 47 security can play a useful role, this document encourages the 48 analysis of related work to discern their applicability, limitations, 49 and coverage of use cases. Such an effort may us espouse innovation 50 to frame an overall architecture and motivate more detailed work on 51 protocols and mechanisms in the future. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on April 30, 2015. 70 Copyright Notice 72 Copyright (c) 2014 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 3. Characteristics of Solutions . . . . . . . . . . . . . . . . 5 90 4. Benefits for the content provider, for the users, for the 91 intermediaries . . . . . . . . . . . . . . . . . . . . . . . 7 92 5. Analysis of Related Work . . . . . . . . . . . . . . . . . . 8 93 6. Architectural Considerations . . . . . . . . . . . . . . . . 9 94 7. Analysis of the Impacts on HTTP/2 . . . . . . . . . . . . . . 9 95 8. Analysis of the Impacts on TLS . . . . . . . . . . . . . . . 9 96 9. Impacts on the current browser architecture . . . . . . . . . 9 97 10. Impacts on the existing deployment / how to make this 98 proposal coexist with the current . . . . . . . . . . . . . . 10 99 11. Privacy Impact . . . . . . . . . . . . . . . . . . . . . . . 10 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 101 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 103 14.1. Informative References . . . . . . . . . . . . . . . . . 10 104 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 107 1. Introduction 109 In the last decade, the generalization of network access, the cloud 110 and the ubiquity of the Web as an application platform has translated 111 into an unprecedented increase in the use of the Internet, 112 facilitated by the development of new web standards and the 113 innovations in mobile technologies. With this growth in use, there 114 has been an increased amount of personal data being sent over multi 115 hop public links. 117 In order to protect the integrity and confidentiality of the online 118 transactions, HTTP traffic can be secured with transport layer 119 security using https. While https is great for e-commerce and 120 banking and while there is a sense of understanding in the user 121 community around the secure nature of https, using TLS and https for 122 the majority of the traffic has performance and functional drawbacks, 123 mainly because the HTTP session is encrypted as a whole. 125 Looking from the privacy and security perspective, it is clear that 126 users must be aware if and when an intermediary node is intercepting 127 their traffic and they have the right to continue or demand higher 128 levels of privacy by encrypting what they deem to be sensitive 129 information. The privacy threshold depends on user's tolerance and 130 the trust they put in the intermediary's reputation, as well as 131 whether the user is the ultimate consent authority for a given 132 connection: for example a parent or employer may take that role for a 133 connection used by a child or employee. 135 Modern web architecture involves sophisticated caching schemes that 136 involve fetching various objects (images, libraries, etc.) from 137 various locations in the path to avoid latency and improve the 138 overall user experience while reducing bandwidth use. This is an 139 important aspect especially in the developing countries, remote 140 locations and in general areas that lack fast network infrastructure. 142 Issues thus arise from the clash of two trends: One is towards 143 enhanced privacy calling for integrity, confidentiality and 144 anonymity. The other one is towards improved performance and lower 145 latency, calling for caching, compression, and adaptability. 147 This is also reflected in the views of important stakeholders. Users 148 want to make informed decisions in regards to whom they trust with 149 their data. They also want to have control over what data they share 150 with whom. 152 Web site owners and content providers on the other hand are keen to 153 get the most cost efficient and reliable way to deliver information 154 and services to their users and customers, while preserving their 155 confidentiality, protecting their privacy and the integrity of their 156 data. 158 As different entities seek to meet the requirements of their 159 stakeholders, they sometimes apply solutions which generate 160 conflicts. Clients act on behalf of end users and solutions may 161 include local caches and browser proxies. Servers act on behalf of 162 content providers and solutions may include the use of CDNs and 163 reverse proxies. Intermediaries operated by communication service 164 providers and network operators act on behalf of users and/or content 165 providers and solutions include means for access network optimization 166 and content filtering. 168 In above context, the use of TLS and https looks like a "black and 169 white approach", or an "all or nothing" approach which doesn't lend 170 itself to resolving above-mentioned conflicts. The question arises: 171 Can "color be added"? 173 TLS is a client server protocol and it serves its purpose perfectly 174 in many client-server scenarios and use cases. But then the web has 175 evolved to become a mesh. Average traffic flows now involve various 176 intermediaries between clients and servers. They add value by 177 performing different functions including multiple levels of 178 optimization. 180 The application of TLS forces point-to-point flows which cuts out 181 intermediaries and can lead to significant drawbacks. It reduces 182 e.g. the optimization options which translates into increasing 183 traffic volumes in access networks, higher latency and overall 184 decreasing quality of experience for users. 186 It can be observed that ignoring the role of intermediaries on the 187 Internet does not necessarily make the Internet more secure. In 188 fact, in some cases it forces various parties to break the TLS 189 promise of e2e integrity and confidentiality in order to meet their 190 legal obligations (enterprises). 192 We suggest the solution to the challenge lies in "adding color". An 193 example of this are fine-grained intermediary-aware end-to-end 194 protocols. 196 Assuming the existence of such a fine-grained protocol, the following 197 benefits could be imagined which leads to satisfying the justified 198 needs of multiple stakeholders: 200 The ability to atomically encrypt objects or even HTTP frames should 201 support this sophisticated caching mechanisms while allowing content 202 providers to avoid distributing their server key material across the 203 network nodes and prevent the risk of compromising their security. 205 2. Objectives 207 Given the short description of the problem above, the following 208 objectives can be derived. 210 1. To improve security and user-controlled privacy. 212 2. To minimize passive interception and man in the middle attacks. 214 3. To allow the client (user) and the server (content provider) to 215 negotiate what and whom they want to give (or not) visibility 216 into their traffic flows. 218 4. To enable multiple levels of optimization that don't conflict 219 with each other and either meet all parties expectations or 220 maximise the benefit to as many involved parties as possible. 222 In a world of TLS and https only, it is difficult to achieve in 223 particular objectives 3. and 4. 225 The challenge therefore is in finding mechanisms or protocols which 226 meet objectives 1. and 2. (e.g. in the way TLS is delivering against 227 those objectives) AND simultaneously provide the added flexibility to 228 leverage the services of 3rd party intermediaries located between 229 client and origin server. 231 3. Characteristics of Solutions 233 From above, one can draw some conclusions about the characteristics 234 possible solutions or new protocols may have to show. Below is a 235 non-exhaustive list. A new fine-grained intermediary-aware end-to- 236 end protocol may need to feature: 238 1. a mechanism to enable users to choose their preferred level of 239 privacy, adequate for a particular context and use case. The 240 context may be determined by the presence or absence of 241 particular intermediaries or proxies which offer particular 242 services (e.g. caching, data compression etc.). 244 2. mechanisms that enable certain communication data to be exchanged 245 securely, whereby the end user shall be able to select the set of 246 security services deemed adequate for a particular communication 247 context (e.g. confidentiality, data integrity, entity 248 authentication etc.). 250 3. mechanisms that enable the end user to select which communication 251 data shall be subject to particular security services (like 252 confidentiality, data integrity etc.). Note that this might be 253 all application level data transferred between server and client, 254 or it might be a subset of application level data. This refers 255 to the notion of "fine-grained" control. 257 4. mechanisms that protect against passive interception and man-in- 258 the-middle attacks. 260 5. mechanisms that allow the two ultimate communication end points, 261 namely client and origin server, to negotiate whether and if so 262 which intermediaries shall be permitted to play a role in 263 delivering application data from origin server to client given 264 particular end user expectations, requirements and preferences, 265 and information about the status of the network between client 266 and server. This refers to the notion of "intermediary-aware 267 end-to-end protocol". 269 6. mechanisms that allow end users or origin server or both to 270 determine in real-time which traffic optimizations are available 271 at the time of communication setup. 273 7. mechanisms that allow end users or origin servers or both to 274 eventually select zero or more optimizations to be applied to 275 traffic flows between origin server and client. 277 8. mechanisms that allow the simultaneous or sequential application 278 of optimizations such that those optimizations on traffic and 279 traffic flow don't conflict with each other. 281 As said, above list is not exhaustive and additional characteristics 282 may be either required or useful. 284 The intent of this draft is not to introduce a solution yet. 285 However, it may help to consider possible elements which might play a 286 role in any solution. One element is "object security". 288 4. Benefits for the content provider, for the users, for the 289 intermediaries 291 An object security approach will allow the different parties to 292 establis end-to-end and hop-by-hop security mechanisms to different 293 data and metadata elements, and therefore address what can be seen as 294 conflicting requirements in terms of optimization and security 295 capabilitites. 297 The following benefits will arise for the different stakeholders: 299 Content providers: 301 o Can select the type of security service that is optimal and 302 sufficient for particular types of content: e.g. confidentiality, 303 integrity protection, entity authentication etc. 305 o Can select which parts of their content shall be secured or not 306 and how content shall be securely retrievable. 308 o Can increase their confidence in secure temporary content storage 309 during delivery through encrypting/signing sensitive content 310 objects. 312 o Can leverage the business services of 3rd parties (intermediaries) 313 through enabling the intermediaries to perform value-added 314 services. Content providers may outsource particular tasks (like 315 caching, or offering higher security level to users) to 316 intermediaries. 318 o When using the services of content delivery networks, can benefit 319 from faster, optimised delivery over the "last mile" (as seen from 320 the perspective of a content delivery network). Content delivery 321 networks can optimise delivery on behalf of content providers over 322 the first and middle mile, however they often rely on other ISPs 323 and mobile network operators to deliver content over the last 324 mile. Intermediaries in the last mile can optimise traffic 325 engineering. 327 Users: 329 o Are able to enjoy sufficient privacy and security as dictated by 330 different use cases and equally their personal preferences (e.g. 331 protection from traffic analysis, integrity of content). 333 o Can benefit from value-added services delivered by intermediaries 334 on behalf of content providers. 336 o Can have access to services offered by intermediaries which 337 enhance end user quality of experience (e.g. malware detection, 338 parental controls). 340 o Can access web resources and services with lower latency and 341 better response times (e.g. through intermediaries performing 342 video pacing or traffic engineering to avoid congestion on 343 particular networks). 345 Intermediaries: 347 o Can play their specific roles in content delivery and 348 communication on behalf of content providers, like 350 * Caching of content on behalf of content providers 352 * Optimisation of content for optimal delivery on behalf of 353 content providers 355 * Video pacing on behalf of content providers. 357 o Can provide value-added services on behalf of users like parental 358 control, malware detection etc. 360 o Can optimise content delivery and data communication within a 361 network they are associated with or control e.g. through traffic 362 engineering and traffic management by taking into account the 363 inherent needs of content types and the explicit real- and non- 364 real-time requirements of content providers and content delivery 365 networks. Thereby, intermediaries contribute to an improved "end- 366 to-end" user experience in the interest of both users and content 367 providers. 369 * Intermediaries are enabled to perform congestion management and 370 can therefore reduce latency and response times. 372 o Can meet regulatory requirements as they may prevail in particular 373 jurisdictions through an approach which is more open and 374 transparent to both users and content providers, and which may be 375 in the national interest. 377 5. Analysis of Related Work 379 The concept of object security is not something new, several 380 approaches targeted at different application areas exist today, and 381 we can even root them at the original S/MIME proposal ([RFC5751]). 383 As one of our first tasks, we intend to perform a detailed analysis 384 of this related work, producing a list of the gaps of each technology 385 solution in the scenarios we foresee. In particular, we have already 386 identified at least a couple of such related work: 388 o JOSE, which stands for "JSON Object Signing and Encryption". It 389 is a series of standards produced by the IETF under the JOSE 390 charter ([1]) offering encryption, digital signatures, and Message 391 Authentication Codes (MACs). 393 o Subresource Integrity ([SRI]), a W3C specification defining 394 mechanisms by which user agents may verify that a fetched resource 395 has been delivered without unexpected manipulation. 397 6. Architectural Considerations 399 The purpose of an object security architecture is to be able to 400 provide more flexible security services than strict end-to-end 401 encryption. A content owner should be able to express what security 402 levels different objects should be associated with. 404 Such an architecture needs to define two types of logical channels 405 between end-points. One channel is strictly end-to-end encrypted 406 where sensitive data is transferred between end points without the 407 risk of third-party access. The second channel is more relaxed in 408 allowing third-party nodes be part of the flow (i.e hop-by-hop 409 encrypted channel). The amount of information exposed in the second 410 channel is determined by the content provider alone or in agreement 411 with the end-user. 413 There are several ways to design an architecture that fulfills these 414 requirements. An important question to analyze is whether an object 415 security architecture should be designed at the application layer or 416 further down the stack as an alternative to TLS. 418 7. Analysis of the Impacts on HTTP/2 420 [[CREF1: TBD]] 422 8. Analysis of the Impacts on TLS 424 [[CREF2: TBD]] 426 9. Impacts on the current browser architecture 428 [[CREF3: TBD]] 430 10. Impacts on the existing deployment / how to make this proposal 431 coexist with the current 433 [[CREF4: TBD]] 435 11. Privacy Impact 437 [[CREF5: TBD]] 439 12. Security Considerations 441 [[CREF6: TBD]] 443 13. Contributors 445 The following people are not listed as authors, but contributed 446 significantly to the discussions leading to this document: Liliana 447 Dinale, Vijay Gurbani, Mike Jones, Eliot Lear, Salvatore Loreto, John 448 Mattsson, Sanjay Mishram, Robert Moskowitz, Kevin Smith, Dan Wing. 450 14. References 452 14.1. Informative References 454 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 455 Mail Extensions (S/MIME) Version 3.2 Message 456 Specification", RFC 5751, January 2010. 458 [SRI] Braun, F., Akhawe, D., Weinberger, J., and M. West, 459 "Subresource Integrity", W3C Working Draft WD-SRI- 460 20140318, March 2014, 461 . 463 Latest version available at [2]. 465 14.2. URIs 467 [1] https://datatracker.ietf.org/wg/jose/charter/ 469 Authors' Addresses 471 Dan Druta 472 AT&T 474 Email: dd5826@att.com 475 Thomas Fossati 476 Alcatel-Lucent 478 Email: thomas.fossati@alcatel-lucent.com 480 Marcus Ihlar 481 Ericsson 483 Email: marcus.ihlar@ericsson.com 485 Guenter Klas 486 Vodafone 488 Email: Guenter.Klas@vodafone.com 490 Diego R. Lopez 491 Telefonica I+D 493 Email: diego.r.lopez@telefonica.com 495 Julian F. Reschke (editor) 496 greenbytes GmbH 498 Email: julian.reschke@greenbytes.de