Mozilla

martin.thomson@gmail.com

Ericsson

goran.ap.eriksson@ericsson.com

Ericsson

christer.holmberg@ericsson.com

An architecture is described for content distribution using a secondary server that might be operated with reduced privileges. This architecture allows a primary server to delegate the responsibility for delivery of the payload of an HTTP response to a secondary server. The secondary server is unable to modify this content. The content is encrypted, which in some cases will prevent the secondary server from learning about the content.

The distribution of content on the web at scale is necessarily highly distributed. Large amounts of content needs large numbers of servers. And distributing those servers closer to clients has a significant, positive impact on performance. A major drawback of existing solutions for content distribution is that a primary server is required to cede control of resources to the secondary server. The secondary server is able to see and modify content that they distribute. There are few technical mechanisms in place to limit the capabilities of servers that provide content for a given origin. Mechanisms like content security policy and sub-resource integrity can be used to prevent modification of resources in some contexts, but these mechanisms are limited in what they can protect and they can impose certain operational costs. For the most part, server operators are forced to limit the content that is served on servers that are not directly under their control or rely on non-technical measures such as contracts and courts to proscribe bad behavior.

This document describes how an primary origin server might securely delegate the responsibility for serving content to a secondary server. The solution comprises three basic components: A delegation component allows a primary server to delegate specific resources to another server. Integrity attributes ensure that the content cannot be modified by the secondary server. Confidentiality protection limits the ability of the secondary server to learn what the content holds. Note that the guarantees provided by confidentiality protection are not strong, see for details. In addition to these basic components, a fourth mechanism provides a client with the ability to learn resource metadata from the primary server prior to making a request for specific resources. This can dramatically improve performance where a client needs to acquire multiple delegated resources. No new mechanisms are described in this document; the application of several existing and separately-proposed protocol mechanisms to this problem is described. A primary server can use these mechanisms to take advantage of secondary servers where concerns about security might have otherwise prevented their use. This might be for content that was previously considered too sensitive for third-party distribution, or to access secondary servers that were previously consider insufficiently trustworthy.

The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document. It’s not shouting; when they are capitalized, they have the special meaning defined in . This document uses the terms client, primary server and secondary server. These terms refer to the three roles played in this architecture. Note that “primary server” as used in this document encompasses the notion of both an origin server and a gateway as defined in .

The out-of-band content encoding provides the basis for delegation of content distribution. A request is made to the primary server, but in place of the complete response only response header fields and an out-of-band content encoding is provided. The out-of-band content encoding directs the client to retrieve content from another resource.

| | | | | Response + OOB CE | |<-----------------------------------+ | | | |GET | | +----------------->| | | | | | 200 | | |<-----------------+ | | | | ]]>

Out-of-band content encoding behaves much like a redirect. In fact, a redirect was considered as part of the early design, but rejected because without defining a new set of 3xx status codes it would change the effective origin of the resource. Furthermore, the content encoding specifically preserves header fields sent by the primary server, rejecting any unauthenticated header fields that might be provided by the secondary server.

An additional request is necessary to retrieve content. This has a negative impact on latency. However, if the secondary server is positioned close to the client, there are several potential benefits: Content hosted in the secondary server that is nearby can be served to those clients without having to traverse a long network path. Using a dedicated secondary server reduces the load on the primary server, allowing it more capacity for serving other requests. If a secondary server is closer to a client, more bandwidth might be available for delivery of content when compared with the link between client and primary server. For some resources, increased bandwidth can counteract the added latency cost of the extra requests, and potentially reduce the time needed to retrieve the entire resource. The problems of providing integrity protection for content delivered in this fashion is discussed in ; confidentiality protection and its limitations is described in ; and reducing the latency impact of making multiple requests for each resource is described in .

The URL used to acquire a resource from a secondary server can be unrelated to the URL of the resource that refers to its contents. This allows a primary server to hide the relationship between content in a secondary server and the original resources that is use that content. Any entity SHOULD be unable to determine the URL of the original resource based on the URL of the secondary server resource alone. This can be achieved by having randomized URLs for secondary resources and maintaining a mapping table, or by using a fixed mapping function with a secret input such as HMAC . Without other information, this would prevent the secondary server from learning which resources are requested from the primary server by observing the requests that it serves for out-of-band content. While in some cases, information about the resource is obtainable by the secondary server cache, see , an unpredictable mapping ensures that other protection mechanisms can be effective if possible.

Ensuring that content is not modified by the secondary server is critical. Information that is acquired from the secondary server is not integrity protected and therefore MUST NOT be used without being authenticated. A cryptographic hash over the content sent in the initial response could be compared against a hash of the content delivered by the secondary server. This is an expansion of the the basic design of . A progressive integrity mechanism like the one described in ensures that there are no significant performance penalties imposed by the integrity protection. Progressive integrity allows for consumption of content as it is delivered without losing integrity protection. A response from the primary server could include an M-I header field with an integrity proof, allowing the content to be delivered out-of-band without any additional header fields.

Confidentiality protection for content is provided by applying an encryption content encoding to content before that content is provided to a secondary server. Much of the value provided by a secondary server derives from its ability to deliver the same content to multiple nearby clients. The more clients that can be delivered the same resource, the greater the efficiency gains. As a result, resources that are provided to many or all clients are the ones that benefit most from caching. This means that unless a resource has access control mechanisms that would prevent the secondary from accessing a resource, the confidentiality protections provided by encrypting content is limited. A secondary server need only independently request resources from the primary server in order to learn everything about the content it is serving, including the mapping of primary URLs to secondary URLs. For instance, employing a web crawler on a web site might reveal the identity of numerous resources and the location of the any out-of-band content for those resources. Confidentiality protection allows resources that are protected by client authentication to remain confidential. Confidentiality protection also improves protections against cross-origin theft of confidential data (see ).

Learning about header fields and out-of-band cache locations for resources in advance of needing to make requests to those resources allows a client to avoid making requests to the primary server. This can greatly improve the performance of applications that make multiple requests of the same server, such as web browsing or video streaming. Without defining any new additional protocol mechanisms, HTTP/2 server push can be used to provide requests, responses and the out-of-band content encoding information describing resources. Since no actual content is included, this requires relatively little data to describe a number of resources. Once this information is available, the client no longer needs to contact the origin server to acquire the described resources. This approach has some significant deployment drawbacks, so explicit data formats for carrying this data might be defined. We need a separate draft on these alternative methods.

Error handling for clients is described in . For idempotent requests, a second request might be made to the primary server. This request would omit any indication of support for out-of-band content coding from the Accept-Encoding header field, plus a link relation indicating the secondary resource and the reason for failure. A primary server can use this information to make informed choices about whether to use content delegation. Non-idempotent requests cannot be safely retried. Therefore, clients cannot retry a a request and provide information about errors to the primary server. For this reason, primary servers SHOULD NOT delegate content for non-idempotent methods.

This document describes a framework whereby content might be distributed to a secondary server, without losing integrity with respect to the content that is distributed. This design relies on integrity and confidentiality for the request and response made to the primary server. These requests MUST be made using HTTP over TLS (HTTPS) only. Though there is a lesser requirement for confidentiality, requests made to the secondary server MUST also be secured using HTTPS.

Content that requires only integrity protection can be safely distributed by a third-party using this design. Entities that make a decision about confidentiality for others have often been shown to be incorrect in the past. An incorrect conclusion have serious consequences. Thus the choice of whether confidentiality protection is needed is quite important. Some confidentiality protection against the secondary server is provided, but that is limited to content that is not otherwise accessible to that server (see ). Only content that has access controls on the primary server that prevent access by the secondary server can retain confidentiality protection. Content with different access control policies MUST use different keying material for encryption. This prevents a client with access to one resource from acquiring keys that can be used for resources they are not authorized to access. Clients that wish to retain control over the confidentiality of responses can omit the out-of-band label from the Accept-Encoding header field on requests, thereby indicating that a direct response is necessary.

The content delegation creates the possibility that a primary server could adopt remotely hosted content. On the web, this is normally limited by Cross-Origin Resource Sharing , which requires that a client first request permission to make a resource accessible to another origin. This document describes a method whereby content hosted on a remote secondary server can be made accessible to another origin. The content of the out-of-band resource is written into the content of a response from the origin. All an origin needs to make this happen is knowledge of the identity of the out-of-band resource, something that might be difficult based on the guidance in , but not infeasible. A client requests this content using any ambient authority available to it (such as HTTP authentication header fields and cookies). The simplest option for reducing the ability to steal content in this fashion is to require that the origin demonstrate that it knows the content of the resource. Unfortunately, this demonstration is difficult without imposing significant performance penalties, so we require a lesser assurance: that the origin knows how to decrypt the content. This makes content confidentiality () mandatory and limits the resources that can be stolen by an origin to those that are already encrypted. Most importantly, only resources for which the origin knows the encryption key can be stolen. For this protection to be effective, origins MUST use different encryption keys for resources with different sets of authorized recipients. Otherwise, an attacker might learn the encryption key for one resource then use that to decrypt a resource that it is not authorized to read. Resources that rely on signature-based integrity protection are made only marginally more difficult to steal, since the origin needs to learn the signing public key. However, this is not expected to be difficult, since confidentiality protection for public keys. Resources that rely on hash-based integrity protection require that the origin learn the hash of the resource.

Using a secondary server reveals a great deal of information to the secondary server about resources even if confidentiality protection is effective. The size of responses and the pattern of requests for resources can reveal information about their contents. When used carefully, padding as described in can obscure the length of responses and reduce the information that the secondary server is able to learn. A random or unpredictable mapping from the primary resource URL on the primary server to the URL of the content is necessary, see . Length hiding for header fields on responses from the primary server might be more important when an out-of-band encoding is used, since the body of the response becomes less variable. Making requests for content to multiple different servers can improve the amount of content length information available to network observers. HTTP/2 multiplexing might have otherwise reduced the exposure of length information, but using out-of-band content encoding could expose lengths for those resources that can be distributed by a secondary server. Note that this is not fundamentally worse than HTTP/1.1 in the absence of pipelining. Padding in HTTP/2 or encrypted content encoding can be used to further obscure lengths.

This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes an Hypertext Transfer Protocol (HTTP) content coding that can be used to describe the location of a secondary resource that contains the payload. This memo introduces a content-coding for HTTP that provides progressive integrity for message contents. This integrity protection can be evaluated on a partial representation, allowing a recipient to process a message as it is delivered while retaining strong integrity protection. The integrity protection can optionally be authenticated with a digital signature. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] A Content-Signature header field is defined for use in HTTP. This header field carries a signature of the payload body of a message. This memo introduces a content-coding for HTTP that allows message payloads to be encrypted. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/encryption .

Magnus Westerlund noted the potential for a violation of the cross origin protections offered in browsers.