One document matched: draft-thomson-http-bc-01.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.36 -->

<!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-01" 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.</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>Clients do not direct queries for <spanx style="verb">https</spanx> URIs to proxies.  Clients configured
with a proxy use the CONNECT pseudo-method (Section 4.3.6 of <xref target="RFC7231"></xref>) with any
explicitly configured or discovered proxies to create an end-to-end tunnel.
Transparent proxies are unable to intercept connections that are protected with
TLS.</t>

<t>This document describes a method that enables shared caching for a limited set
of <spanx style="verb">https</spanx> resources, as selected by the server.  The server conditionally
delegates the hosting of secure content to itself.  This delegation includes a
marker that signals permission for 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.</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.
To enable caching, the primary and secondary servers can be the same server.</t>

<t>A client that signals a willingness to support delegation is provided with a
response that uses a proxy-enabled out-of-band encoding that behaves identically
to the out-of-band encoding defined in <xref target="I-D.reschke-http-oob-encoding"></xref>.  The
out-of-band encoding identifies a secondary resource and implicitly indicates
that the client is willing to use a proxy and that the server allows this use.
The client is then able to request the secondary resource from 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 secondary
server in <xref target="SCD"></xref>.  However, all of the considerations that apply to having a
secondary server host content apply instead 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 server 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 only indicates
willingness to use the secure content delegation mechanism.</t>

<t>A new <spanx style="verb">oobp</spanx> content encoding is defined.  The <spanx style="verb">oobp</spanx> content encoding is
identical to the <spanx style="verb">out-of-band</spanx> content encoding, with the following additional
conditions:</t>

<t><list style="symbols">
  <t>A client MUST NOT signal support for <spanx style="verb">oobp</spanx> content encoding unless it is
using a proxy cache and it is willing to direct requests to that proxy.</t>
  <t>A server MUST NOT encode a response using the <spanx style="verb">oobp</spanx> content encoding unless
it permits the request to be made to a proxy cache.</t>
  <t>The <spanx style="verb">oobp</spanx> content encoding MUST NOT be used to encode the contents of a
request.  The <spanx style="verb">out-of-band</spanx> content encoding is sufficient for that purpose.</t>
</list></t>

<t>Using a different content encoding name means that a resource using secure
content delegation to a secondary server <xref target="SCD"></xref> does not inadvertently trigger a
request via a proxy.</t>

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

<t>The <spanx style="verb">oobp</spanx> content encoding clearly indicates that the client is permitted to
retrieve content from a proxy-cache.</t>

<t>Servers that use the <spanx style="verb">oobp</spanx> content encoding MUST 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>.  Clients MUST NOT send a request via a
proxy if these headers are not present.  Absence of these header fields indicate
an error on the part of the origin server, since integrity and confidentiality
protection are mandatory.</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>

<t><list style="hanging">
  <t hangText='Issue:'>
  What signal do we need from the proxy cache that it supports receiving
requests with an <spanx style="verb">https://</spanx> scheme?  Can we expect that a proxy cache will
happily accept a request for an HTTPS URL?  What if they ignore the scheme and
send the request in the clear?</t>
</list></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, or from hints like the “prefetch” link relation
<xref target="HINTS"></xref>.  To avoid a potential waste of resources as a result of receiving
complete responses, speculative requests might be limited to HEAD requests;
alternatively, 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.  Clients MAY then make the request directly to the origin
server, or - if request can be safely retried - retry a request without the
out-of-band token in the Accept-Encoding header field.</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" >
  <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='June' day='29' year='2016' />

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

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-encryption-encoding-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-encryption-encoding-02.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='June' day='30' 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.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-http-mice-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-http-mice-01.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 F. Reschke'>
    <organization />
</author>

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

<date month='July' day='5' 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-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-reschke-http-oob-encoding-07.txt' />
</reference>


<reference anchor="HINTS" >
  <front>
    <title>Resource Hints</title>
    <author initials="I." surname="Grigorik">
      <organization></organization>
    </author>
    <date year="2015" month="May" day="27"/>
  </front>
  <seriesInfo name="W3C TR" value=""/>
</reference>


    </references>



  </back>
</rfc>