One document matched: draft-thomson-http-scd-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-thomson-http-scd-00" category="std">

  <front>
    <title abbrev="Secure Content Delegation">An Architecture for Secure Content Delegation using HTTP</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="G." surname="Eriksson" fullname="Göran AP Eriksson">
      <organization>Ericsson</organization>
      <address>
        <email>goran.ap.eriksson@ericsson.com</email>
      </address>
    </author>
    <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization>Ericsson</organization>
      <address>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>

    <date year="2016"/>

    
    
    

    <abstract>


<t>An architecture is described for content distribution via third-party content
distribution networks with reduced privileges.  This architecture allows an
origin server to delegate the responsibility for delivery of the payload of an
HTTP response to a third party.  That party is unable to modify this content.
The content is encrypted, which in some cases will prevent the third party from
learning about the content.</t>



    </abstract>


  </front>

  <middle>


<section anchor="content-distribution-security" title="Content Distribution Security">

<t>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.</t>

<t>This has led to large networks of content distribution servers, in some cases
operated by web sites, but often run by third parties in service to sites that
don’t have the resources to operate a network at very large scales.  A content
distribution network (CDN) aims to dramatically improve the performance of
content delivery by moving content closer to clients and by offloading the
delivery responsibility to servers that are highly optimized for that task.</t>

<t>A major drawback of existing solutions for content distribution is that an
origin is required to yield control over their content to the CDN.  A CDN is
able to see and modify content that they distribute.  In some cases, expediency
dictates that the CDN be given control over the entire origin.</t>

<t>There are few technical mechanisms in place to limit the capabilities of a CDN.
Mechanisms like content security policy <xref target="CSP"></xref> and sub-resource integrity <xref target="SRI"></xref>
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, operators of origin servers either limit
the content that is served using the CDN or rely on non-technical measures such
as contracts and courts to proscribe bad behavior.</t>

<section anchor="secure-content-delegation" title="Secure Content Delegation">

<t>This document describes how an origin server might securely delegate the
responsibility for serving content to a CDN.  The solution comprises three basic
components:</t>

<t><list style="symbols">
  <t>A delegation component allows an origin server to delegate specific resources
to another server.</t>
  <t>Integrity attributes ensure that the content cannot be modified by the
delegated server.</t>
  <t>Confidentiality protection limits the ability of the delegated server to learn
what the content holds.</t>
</list></t>

<t>Note that the guarantees provided by confidentiality protection are not strong,
see <xref target="confidentiality"/> for details.</t>

<t>In addition to these basic components, a fourth mechanism provides a client with
the ability to learn resource metadata from the origin prior to making a request
for specific resources.  This can dramatically improve performance where a
client needs to acquire multiple delegated resources.</t>

<t>No new mechanisms are described in this document; the application of several
existing and separately-proposed protocol mechanisms to this problem is
described.  An origin server can use these mechanisms to take advantage of
content distribution networks 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 for a CDN provider that might not
otherwise be used.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>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 <xref target="RFC2119"></xref>.</t>

<t>This document uses the terms client, CDN, and origin server.  These terms refer
to the three roles played in this architecture.  Note that “origin server” as
used in this document encompasses both origin servers and gateways as defined in
<xref target="RFC7230"></xref>.</t>

</section>
</section>
<section anchor="out-of-band-content-encoding" title="Out-of-Band Content Encoding">

<t>The out-of-band content encoding <xref target="I-D.reschke-http-oob-encoding"></xref> provides the
basis for delegation of content distribution.  A request is made to the origin
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.</t>

<figure title="Using Out-of-Band Content Encoding" anchor="ex-oob"><artwork type="drawing"><![CDATA[
   Client           Cache/CDN           Server
     |                  |                 |
     | Request          |                 |
     +----------------------------------->|
     |                  |                 |
     |                  Response + OOB CE |
     |<-----------------------------------+
     |                  |                 |
     |GET               |                 |
     +----------------->|                 |
     |                  |                 |
     |              200 |                 |
     |<-----------------+                 |
     |                  |                 |
]]></artwork></figure>

<t>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
<xref target="RFC6454"></xref> of the resource.  Furthermore, the content encoding specifically
preserves header fields sent by the origin server, rejecting any unauthenticated
header fields that might be provided by the CDN.</t>

<section anchor="performance-trade-off" title="Performance Trade-Off">

<t>An additional request is necessary to retrieve content.  This has a negative
impact on latency.  However, if the CDN server is positioned close to the
client, there are several potential benefits:</t>

<t><list style="hanging">
  <t hangText='Fewer bit-miles:'>
  Content hosted in the CDN that is nearby can be served to those clients
without having to traverse a long network path.</t>
  <t hangText='Better server resource allocation:'>
  Using a dedicated content delivery server reduces the load on the origin
server, allowing it more capacity for serving other requests.</t>
  <t hangText='Lower time to last byte:'>
  For some resources, the proximity of the CDN might also permit greater
network throughput.  Increased bandwidth can counteract the added latency cost
of the extra requests, and potentially reduce the time needed to retrieve the
entire resource.</t>
  <t hangText='Better throughput:'>
  If a CDN is closer to a client, more bandwidth might be available for delivery
of content when compared with the link between client and origin server.</t>
</list></t>

<t>The problems of providing integrity protection for content delivered in this
fashion is discussed in <xref target="integrity"/>; confidentiality protection and its
limitations is described in <xref target="confidentiality"/>; and reducing the latency impact
of making multiple requests for each resource is described in <xref target="map"/>.</t>

</section>
<section anchor="urls" title="Confidentiality of Resource Identity">

<t>The URL used to acquire a resource from a CDN can be unrelated to the URL of the
resource that refers to its contents.  This allows an origin server to hide the
relationship between content in a CDN and the original resources that is served
by that content.</t>

<t>Any entity SHOULD be unable to determine the URL of the original resource based
on the URL of the CDN resource alone.  This can be achieved by having randomized
URLs for CDN resources and maintaining a mapping table, or by using a fixed
mapping function with a secret input such as HMAC <xref target="RFC2104"></xref>.</t>

<t>Without other information, this would prevent the CDN from learning which
resources are requested from the origin server by observing the requests that it
serves for out-of-band content.  Note that in some cases, information about the
resource is readily obtainable by the CDN cache, see <xref target="confidentiality"/>, an
unpredictable mapping ensures that other protection mechanisms can be effective
if possible.</t>

</section>
</section>
<section anchor="integrity" title="Content Integrity">

<t>Ensuring that content is not modified by the CDN is crucial to ensuring that
content cannot be improperly modified.  Information that is acquired from the
CDN is not integrity protected and therefore MUST NOT be used without being
authenticated.</t>

<t>Several options are available for authenticating content provided by the CDN:</t>

<t><list style="symbols">
  <t>A cryptographic hash over the content sent in the initial response could be
compared against a hash of the content delivered by the CDN.  This is the
basic design of <xref target="SRI"></xref>.</t>
  <t>A digital signature could cover the content stored by the CDN.  A design that
uses this approach is described in <xref target="I-D.thomson-http-content-signature"></xref>.</t>
</list></t>

<t>A progressive integrity mechanism like the one described in
<xref target="I-D.thomson-http-mice"></xref> is perhaps the most flexible approach.  It allows for
progressive consumption of content without losing integrity protection.  This
supports both hash- and signature-based integrity protection for out-of-band
content:</t>

<t><list style="symbols">
  <t>A response from the origin 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.</t>
  <t>A response from the origin server could include a Crypto-Key header field with
a signature public key.  The out-of-band response could then include a M-I
header field with the signature in addition to the content.</t>
</list></t>

</section>
<section anchor="confidentiality" title="Content Confidentiality">

<t>Confidentiality protection for content is provided by applying an encryption
content encoding <xref target="I-D.ietf-httpbis-encryption-encoding"></xref> to content before that
content is provided to a CDN.</t>

<t>Much of the value provided by a CDN 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.</t>

<t>This means that unless a resource has access control mechanisms that would
prevent the CDN from accessing a resource, the confidentiality protections
provided by encrypting content is limited.  A CDN need only independently
request resources from the origin server in order to learn everything about the
content it is serving, including the mapping of origin server URLs to CDN
resource 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.</t>

<t>Nonetheless, confidentiality protection MUST be used to prevent cross-origin
theft of confidential data (see <xref target="sec-cors"/>).</t>

</section>
<section anchor="map" title="Resource Map">

<t>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 origin server.  This can greatly improve the performance
of applications that make multiple requests of the same server, such as web
browsing or video streaming.</t>

<t>Without defining any new additional protocol mechanisms, HTTP/2 server push
<xref target="RFC7540"></xref> 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.</t>

<t>This approach has some signficant deployment drawbacks, so explicit data formats
for carrying this data might be defined.</t>

<t><list style="hanging">
  <t hangText='Note:'>
  We need a separate draft on these alternative methods.</t>
</list></t>

</section>
<section anchor="error-handling" title="Error Handling">

<t>Error handling for clients is described in <xref target="I-D.reschke-http-oob-encoding"></xref>.</t>

<t>For idempotent requests, a second request might be made to the origin 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.</t>

<t>An origin server can use this information to inform choices about whether to use
content delegation.</t>

<t>Non-idempotent requests cannot be safely retried.  Therefore, clients cannot
retry a a request and provide information about errors to the origin server.
For this reason, origin servers SHOULD NOT delegate content for non-idempotent
methods.</t>

</section>
<section anchor="security" title="Security Considerations">

<t>This document describes a framework whereby content might be distributed to a
CDN, without losing integrity with respect to the content that is distributed.</t>

<t>This design relies on integrity and confidentiality for the request and response
made to the origin server.  These requests MUST be made using HTTP over TLS
(HTTPS) <xref target="RFC2818"></xref> only.  Though there is a lesser requirement for
confidentiality, requests made to the CDN cache MUST also be secured using HTTPS.</t>

<section anchor="confidentiality-protection-limitations" title="Confidentiality Protection Limitations">

<t>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.</t>

<t>Some confidentiality protection against the CDN is provided, but that is limited
to content that is not otherwise accessible to that server (see
<xref target="confidentiality"/>).  Only content that has access controls on the origin
server that prevent access by the CDN can retain confidentiality protection.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="sec-cors" title="Cross-Origin Access">

<t>The content delegation creates the possibility that an origin server could adopt
remotely hosted content.  On the web, this is normally limited by Cross-Origin
Resource Sharing <xref target="CORS"></xref>, which requires that a client first request permission
to make a resource accessible to another origin.</t>

<t>This document describes a method whereby content hosted on a remote 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 <xref target="urls"/>, but not infeasible.
A client requests this content using any ambient authority available to it (such
as HTTP authentication header fields and cookies).</t>

<t>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.</t>

<t>This makes content confidentiality <xref target="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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="traffic-analysis" title="Traffic Analysis">

<t>Using a CDN reveals a great deal of information to the CDN 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
<xref target="I-D.ietf-httpbis-encryption-encoding"></xref> can obscure the length of responses and
reduce the information that the CDN is able to learn.</t>

<t>A random or unpredictable mapping from the primary resource URL on the origin to
the URL of the content is necessary, see <xref target="urls"/>.</t>

<t>Length hiding for header fields on responses the origin server might be more
important when an out-of-band encoding is used, since the body of the response
becomes less variable.</t>

<t>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 CDN.  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.</t>

</section>
</section>
<section anchor="iana" title="IANA Considerations">

<t>This document has no IANA actions.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference anchor='I-D.reschke-http-oob-encoding'>
<front>
<title>'Out-Of-Band' Content Coding for HTTP</title>

<author initials='J' surname='Reschke' fullname='Julian Reschke'>
    <organization />
</author>

<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
    <organization />
</author>

<date month='March' day='17' year='2016' />

<abstract><t>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.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-reschke-http-oob-encoding-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-reschke-http-oob-encoding-04.txt' />
</reference>



<reference anchor='I-D.thomson-http-mice'>
<front>
<title>Merkle Integrity Content Encoding</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='January' day='28' year='2016' />

<abstract><t>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.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-http-mice-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-http-mice-00.txt' />
</reference>



<reference  anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>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.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC2104' target='http://www.rfc-editor.org/info/rfc2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'><organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></author>
<date year='1997' month='February' />
<abstract><t>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</t></abstract>
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>



<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>



<reference  anchor='RFC6454' target='http://www.rfc-editor.org/info/rfc6454'>
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='December' />
<abstract><t>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]</t></abstract>
</front>
<seriesInfo name='RFC' value='6454'/>
<seriesInfo name='DOI' value='10.17487/RFC6454'/>
</reference>


<reference anchor="CSP" target="https://w3c.github.io/webappsec-csp/2/">
  <front>
    <title>Content Security Policy Level 2</title>
    <author initials="M." surname="West">
      <organization></organization>
    </author>
    <author initials="A." surname="Barth">
      <organization></organization>
    </author>
    <author initials="D." surname="Veditz">
      <organization></organization>
    </author>
    <date year="2015" month="August" day="29"/>
  </front>
</reference>
<reference anchor="SRI" target="https://w3c.github.io/webappsec-subresource-integrity">
  <front>
    <title>Subresource Integrity</title>
    <author initials="D." surname="Akhawe">
      <organization></organization>
    </author>
    <author initials="F." surname="Braun">
      <organization></organization>
    </author>
    <author initials="F." surname="Marier">
      <organization></organization>
    </author>
    <author initials="J." surname="Weinberger">
      <organization></organization>
    </author>
    <date year="2015" month="November" day="13"/>
  </front>
</reference>
<reference anchor="CORS" target="https://www.w3.org/TR/cors/">
  <front>
    <title>Cross-Origin Resource Sharing</title>
    <author initials="A." surname="van Kesteren">
      <organization></organization>
    </author>
    <date year="2014" month="January" day="16"/>
  </front>
</reference>




<reference anchor='I-D.thomson-http-content-signature'>
<front>
<title>Content-Signature Header Field for HTTP</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='July' day='2' year='2015' />

<abstract><t>A Content-Signature header field is defined for use in HTTP.  This header field carries a signature of the payload body of a message.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-http-content-signature-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-http-content-signature-00.txt' />
</reference>



<reference anchor='I-D.ietf-httpbis-encryption-encoding'>
<front>
<title>Encrypted Content-Encoding for HTTP</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='March' day='21' year='2016' />

<abstract><t>This memo introduces a content-coding for HTTP that allows message payloads to be encrypted.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-encryption-encoding-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-encryption-encoding-01.txt' />
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

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

</section>


  </back>
</rfc>