One document matched: draft-thomson-http-bc-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-bc-00" category="std">

  <front>
    <title abbrev="Blind Cache">Caching Secure HTTP Content using Blind Caches</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>A mechanism is described whereby a server can use client-selected shared cache.</t>



    </abstract>


  </front>

  <middle>


<section anchor="shared-caching-for-https" title="Shared Caching for HTTPS">

<t>Shared caches allow an HTTP server to offload the responsibility for delivering
certain content.  Content in the shared cache can be accessed efficiently by
multiple clients, saving the origin server from having to serve those requests
and ensuring that clients receive responses to cached requests more quickly.</t>

<t>Proxy caching is the most common configuration for shared caching.  A proxy
cache is either explicitly configured by a client, discovered as a result of
being automatically configured, or interposed automatically by an on-path
network entity (this latter case being called a transparent proxy).</t>

<t>HTTPS <xref target="RFC2818"></xref> prevents the use of proxies by creating an authenticated
end-to-end connection to the origin server or its gateway that is authenticated.
This provides a critical protection against man-in-the-middle attacks, but it
also prevents the proxy from acting as a shared cache.</t>

<t>Thus, clients use the CONNECT pseudo-method (Section 4.3.6 of <xref target="RFC7231"></xref>) with any
explicitly configured proxies to create an end-to-end tunnel and will refuse to
send a query for an <spanx style="verb">https</spanx> URI to a proxy.</t>

<t>This document describes a method for conditionally delegating the hosting of
secure content to the same server.  This delegation allows a client to send a
request for an <spanx style="verb">https</spanx> resource via a proxy rather than insisting on an
end-to-end TLS connection.  This enables shared caching for a limited set of
<spanx style="verb">https</spanx> resources, as selected by the server.</t>

<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 term “proxy cache” to refer to a proxy <xref target="RFC7230"></xref> that
operates an HTTP cache <xref target="RFC7234"></xref>.</t>

</section>
</section>
<section anchor="same-host-secure-content-delegation" title="Same-Host Secure Content Delegation">

<t>The secure content delegation mechanism defined in <xref target="SCD"></xref> is used to create a
separate resource that contains encrypted and integrity protected content.</t>

<t>A client that signals a willingness to support this feature can be provided an
response with an out-of-band encoding <xref target="I-D.reschke-http-oob-encoding"></xref> that
identifies this resource.  The client can then make a request for that content
to a proxy cache rather than directly to the origin server.</t>

<t>In this document, the origin server is able to act in the role of the CDN in
<xref target="SCD"></xref>.  However, all of the considerations that apply to having a third party
host content apply to the proxy cache.  Thus, integrity and confidentiality
protections against the proxy cache are the primary consideration.</t>

<section anchor="signaling-presence-of-a-proxy" title="Signaling Presence of a Proxy">

<t>Without a clear signal from the client that a caching proxy is present, an
origin is unable to send a response with out-of-band encoding.  A value of
<spanx style="verb">out-of-band</spanx> in the Accept-Encoding header field might only indicate
willingness to use the secure content delegation mechanism.</t>

<t>The BC header field indicates that a client is connected to a proxy cache that
it is willing to use for out-of-band requests.  The value of the BC header field
is a simple boolean, represented as a “0” or “1”.  A value that is present and
set to “1” indicates that a proxy cache is present and available for use.  This
header field can be used even if the current request was not routed via a proxy.</t>

<figure><artwork type="abnf"><![CDATA[
   BC = "0" / "1"
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='Issue:'>
  What signal do we need from the proxy cache that it supports this mode of
operation?  Can we expect that a proxy cache will happily accept a request for
an HTTPS URL?</t>
  <t hangText='Issue:'>
  Do we want to identify the proxy so that the origin can make some sort of
judgment about the proxy?  Probably not.  We shouldn’t be relying on the
origin server making judgments about the character of proxies.</t>
</list></t>

</section>
<section anchor="enabling-proxy-use" title="Enabling Proxy Use">

<t>It is not sufficient to couple the acceptance and use of out-of-band content
encoding with the use of a proxy.  Without an additional signal, a resource
using secure content delegation to a CDN <xref target="SCD"></xref> could trigger a request via a
proxy.</t>

<t>The security properties of delegation via a CDN and via a caching proxy are
similar only to the extent that a third party is involved.  However, it might be
the case that the CDN has a stronger relationship with the origin server and
additional constraints on its actions, such as contractual limitations.  Such
constraints might make delegation to the CDN acceptable to the origin server.  A
caching proxy might not be considered acceptable.</t>

<t>Therefore, a clear signal from the origin server is needed to allow the client
to identify which resources are safe to retrieve from a proxy-cache.  A <spanx style="verb">proxy</spanx>
extension to the JSON format defined in <xref target="I-D.reschke-http-oob-encoding"></xref> is added
that signals to the client that the out-of-band content MAY be retrieved by
making a request to a proxy.</t>

<t>The <spanx style="verb">proxy</spanx> attribute is a boolean value.  In its absence, the value is assumed
to be false.  If present and set to true, a client can send the request for the
out-of-band content to a proxy instead of the identified server.</t>

<t>Clients MUST NOT send a request via a proxy if the message containing the
out-of-band content encoding does not include header fields for message
integrity and encryption, such as the M-I header field <xref target="I-D.thomson-http-mice"></xref>
or the Crypto-Key header field <xref target="I-D.ietf-httpbis-encryption-encoding"></xref>.  Absence
of these header fields indicate an error on the part of the origin server, since
integrity and confidentiality protection are mandatory.</t>

<t><list style="hanging">
  <t hangText='Alternative:'>
  The <spanx style="verb">proxy</spanx> attribute might be replaced by a rule that stated that same-origin
out-of-band encoding implied permission to route via a proxy.  However, the
gain here is minimal, it saves only on the explicit indication.</t>
</list></t>

</section>
<section anchor="proxy-identification-and-authentication" title="Proxy Identification and Authentication">

<t>This mechanism does not work with a transparent caching proxy.  Since the
request is made over end-to-end HTTPS in the absence of a proxy, the feature
will not be used unless the proxy is known to the client.</t>

<t>A proxy cache MUST therefore be expressly configured or discovered.  This
produces a name and possibly a port number for the proxy.  The proxy MUST be
contacted using HTTPS <xref target="RFC2818"></xref> and authenticated using the configured or
discovered domain name.</t>

</section>
</section>
<section anchor="performance-optimizations" title="Performance Optimizations">

<t>As noted in <xref target="SCD"></xref>, the secondary request required by out-of-band content
encoding imposes a performance penalty.  This can be mitigated by priming
clients with information about the location and disposition of resources prior
to the client making a request.  A resource map described in <xref target="SCD"></xref> might be
provided to clients to eliminate the latency involved in making requests of the
origin server for resources that might be cached.</t>

<section anchor="proxy-cache-priming" title="Proxy Cache Priming">

<t>A client that makes a request of an origin server via an unprimed proxy cache will
suffer additional latency as a consequence of the cache having to make a request
to the origin server.</t>

<t>The following options are possible:</t>

<t><list style="symbols">
  <t>Clients can speculatively make requests to a proxy cache based on information
it learns from a resource map.  To avoid a potential waste of resources as a
result of receiving complete responses, these might either be limited to HEAD
requests; HTTP/2 <xref target="RFC7540"></xref> flow control might be used to allow only limited
information to be sent.</t>
  <t>The origin server might provide the proxy cache with “prefetch” link relations
in responses to requests for secondary resources.  These link relations might
identify other resources that the proxy might retrieve speculatively.  This
does not improve the latency of the initial request, but could improve
subsequent requests.</t>
</list></t>

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

<t>All the considerations of <xref target="SCD"></xref> apply.  In particular, content that is
distributed with the assistance of a proxy cache MUST include integrity and
confidentiality protection.  That means that the M-I header field
<xref target="I-D.thomson-http-mice"></xref> and the Crypto-Key header field
<xref target="I-D.ietf-httpbis-encryption-encoding"></xref> or equivalent information MUST be present
in responses that include an out-of-band content encoding.</t>

<t>Clients that receive a response without the information necessary to ensure
integrity and confidentiality protection against a proxy cache MUST NOT make a
request to a proxy to retrieve that response.  Clients could treat such a
response as failed, make the request directly to the origin server, or retry a
request without the out-of-band token in the Accept-Encoding header field (for
idempotent methods only).</t>

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

<t>This document has no IANA actions.  It should.</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='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='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='RFC7234' target='http://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' 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 defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</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>


<reference anchor="SCD" target="draft-eriksson-http-scd.html">
  <front>
    <title>An Architecture for Secure Content Delegation using HTTP</title>
    <author initials="G." surname="Ericsson">
      <organization></organization>
    </author>
    <author initials="C." surname="Holmberg">
      <organization></organization>
    </author>
    <author initials="M." surname="Thomson">
      <organization></organization>
    </author>
    <date year="2016" month="February" day="07"/>
  </front>
</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>



<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>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC7231' target='http://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</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 defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</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>




    </references>



  </back>
</rfc>