| Network Working Group | D. Druta |
| Internet-Draft | AT&T |
| Intended status: Standards Track | T. Fossati |
| Expires: April 30, 2015 | Alcatel-Lucent |
| M. Ihlar | |
| Ericsson | |
| G. Klas | |
| Vodafone | |
| D. Lopez | |
| Telefonica I+D | |
| J. Reschke, Ed. | |
| greenbytes | |
| October 27, 2014 |
A Rationale for Fine-grained Intermediary-aware End-to-End Protocols
draft-reschke-objsec-00
A tremendous growth in different uses of the Internet has led to a growing need to protect data sent over public networks, including data sent via HTTP. Resorting to the use of end-to-end TLS and https for the majority of traffic looks at first like a most feasible response. However, the more sophisticated the web architecture becomes as it goes beyond the simple client-server model, the more the end-to-end use of TLS shows its downside as it excludes the use of beneficial intermediaries like caches or proxies that provide instrumental services. The need for greater privacy seems to collide with the equally growing desire for better end-to-end performance and user experience. As an example, the use of TLS and https often appears to maximise the benefit for the first but not the benefit for the combination of both.
This document describes this dilemma and lays out a number of objectives of what should ideally be achieved, namely catering for sufficient security and privacy whilst providing users with the opportunity to make use of intermediaries' services where considered beneficial. We then introduce a number of characteristics potential solutions could have, with the hope that those will steer us towards suitable protocol mechanisms and data formats. End-to-end protocols which are aware of intermediaries should enable users and/or content providers to exercise fine-grained control over what intermediaries shall be able to do and what exposure to data or metadata they shall be permitted to get. The document then highlights anticipated benefits to key stakeholders like users, content providers and intermediaries. As elements like object security can play a useful role, we encourage the analysis of related pieces of work in order to discern their applicability, limitations, and coverage of use cases. This will allow us to frame an overall architecture and motivate more detailed work on protocols and mechanisms in the future.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
In the last decade, the generalization of network access, the cloud and the ubiquity of the Web as an application platform has translated into an unprecedented increase in the use of the Internet, facilitated by the development of new web standards and the innovations in mobile technologies. With this growth in use, there has been an increased amount of personal data being sent over multi hop public links.
In order to protect the integrity and confidentiality of the online transactions, HTTP traffic can be secured with transport layer security using https. While https is great for e-commerce and banking and while there is a sense of understanding in the user community around the secure nature of https, using TLS and https for the majority of the traffic has performance and functional drawbacks, mainly because the HTTP session is encrypted as a whole.
Looking from the privacy and security perspective, it is clear that users must be aware if and when an intermediary node is intercepting their traffic and they have the right to continue or demand higher levels of privacy by encrypting what they deem to be sensitive information. The privacy threshold depends on user's tolerance and the trust they put in the intermediary's reputation, as well as whether the user is the ultimate consent authority for a given connection: for example a parent or employer may take that role for a connection used by a child or employee.
Modern web architecture involves sophisticated caching schemes that involve fetching various objects (images, libraries, etc.) from various locations in the path to avoid latency and improve the overall user experience while reducing bandwidth use. This is an important aspect especially in the developing countries, remote locations and in general areas that lack fast network infrastructure.
Issues thus arise from the clash of two trends: One is towards enhanced privacy calling for integrity, confidentiality and anonymity. The other one is towards improved performance and lower latency, calling for caching, compression, and adaptability.
This is also reflected in the views of important stakeholders. Users want to make informed decisions in regards to whom they trust with their data. They also want to have control over what data they share with whom.
Web site owners and content providers on the other hand are keen to get the most cost efficient and reliable way to deliver information and services to their users and customers, while preserving their confidentiality, protecting their privacy and the integrity of their data.
As different entities seek to meet the requirements of their stakeholders, they sometimes apply solutions which generate conflicts. Clients act on behalf of end users and solutions may include local caches and browser proxies. Servers act on behalf of content providers and solutions may include the use of CDNs and reverse proxies. Intermediaries operated by communication service providers and network operators act on behalf of users and/or content providers and solutions include means for access network optimization and content filtering.
In above context, the use of TLS and https looks like a "black and white approach", or an "all or nothing" approach which doesn't lend itself to resolving above-mentioned conflicts. The question arises: Can "color be added"?
TLS is a client server protocol and it serves its purpose perfectly in many client-server scenarios and use cases. But then the web has evolved to become a mesh. Average traffic flows now involve various intermediaries between clients and servers. They add value by performing different functions including multiple levels of optimization.
The application of TLS forces point-to-point flows which cuts out intermediaries and can lead to significant drawbacks. It reduces e.g. the optimization options which translates into increasing traffic volumes in access networks, higher latency and overall decreasing quality of experience for users.
It can be observed that ignoring the role of intermediaries on the Internet does not necessarily make the Internet more secure. In fact, in some cases it forces various parties to break the TLS promise of e2e integrity and confidentiality in order to meet their legal obligations (enterprises).
We suggest the solution to the challenge lies in "adding color". An example of this are fine-grained intermediary-aware end-to-end protocols.
Assuming the existence of such a fine-grained protocol, the following benefits could be imagined which leads to satisfying the justified needs of multiple stakeholders:
The ability to atomically encrypt objects or even HTTP frames should support this sophisticated caching mechanisms while allowing content providers to avoid distributing their server key material across the network nodes and prevent the risk of compromising their security.
Given the short description of the problem above, the following objectives can be derived.
In a world of TLS and https only, it is difficult to achieve in particular objectives 3. and 4.
The challenge therefore is in finding mechanisms or protocols which meet objectives 1. and 2. (e.g. in the way TLS is delivering against those objectives) AND simultaneously provide the added flexibility to leverage the services of 3rd party intermediaries located between client and origin server.
From above, one can draw some conclusions about the characteristics possible solutions or new protocols may have to show. Below is a non-exhaustive list. A new fine-grained intermediary-aware end-to-end protocol may need to feature:
As said, above list is not exhaustive and additional characteristics may be either required or useful.
The intent of this draft is not to introduce a solution yet. However, it may help to consider possible elements which might play a role in any solution. One element is "object security".
An object security approach will allow the different parties to establis end-to-end and hop-by-hop security mechanisms to different data and metadata elements, and therefore address what can be seen as conflicting requirements in terms of optimization and security capabilitites.
The following benefits will arise for the different stakeholders:
Content providers:
Users:
Intermediaries:
The concept of object security is not something new, several approaches targeted at different application areas exist today, and we can even root them at the original S/MIME proposal ([RFC5751]).
As one of our first tasks, we intend to perform a detailed analysis of this related work, producing a list of the gaps of each technology solution in the scenarios we foresee. In particular, we have already identified at least a couple of such related work:
The purpose of an object security architecture is to be able to provide more flexible security services than strict end-to-end encryption. A content owner should be able to express what security levels different objects should be associated with.
Such an architecture needs to define two types of logical channels between end-points. One channel is strictly end-to-end encrypted where sensitive data is transferred between end points without the risk of third-party access. The second channel is more relaxed in allowing third-party nodes be part of the flow (i.e hop-by-hop encrypted channel). The amount of information exposed in the second channel is determined by the content provider alone or in agreement with the end-user.
There are several ways to design an architecture that fulfills these requirements. An important question to analyze is whether an object security architecture should be designed at the application layer or further down the stack as an alternative to TLS.
The following people are not listed as authors, but contributed significantly to the discussions leading to this document: Liliana Dinale, Vijay Gurbani, Mike Jones, Eliot Lear, Salvatore Loreto, John Mattsson, Sanjay Mishram, Robert Moskowitz, Kevin Smith, Dan Wing.
| [RFC5751] | Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. |
| [SRI] | Braun, F., Akhawe, D., Weinberger, J. and M. West, "Subresource Integrity", W3C Working Draft WD-SRI-20140318, March 2014. Latest version available at |