One document matched: draft-thomson-tls-acp-00.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-thomson-tls-acp-00">
  <front>
    <title abbrev="ACP">
      Authenticated Content Promise Extension for (D)TLS
    </title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>Suite 300</street>
          <street>650 Castro Street</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>US</country>
        </postal>

        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2014"/>
    <area>Security</area>
    <workgroup>TLS</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Content</keyword>
    <keyword>Web</keyword>
    <keyword>Promise</keyword>

    <abstract>
      <t>
        This document describes an extension to Transport Layer Security (TLS) and Datagram TLS
        (DTLS) that enables the negotiation of a promise to protect session content from
        modification and eavesdropping by third parties.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
        <xref target="I-D.ietf-rtcweb-overview">WebRTC</xref> creates a new understanding of the way
        that "user-generated content" is used on the world wide web.  The established definition
        identifies content that is generated by users and used by sites; after all, the primary mode
        of interaction on the web is between users and sites.
      </t>
      <t>
        WebRTC changes that by enabling users to communicate directly, with secure channels between
        established between user agents (or browsers).  These channels might be established with the
        aid of a web site, but the content of the communication session can be made inaccessible to
        the site <xref target="I-D.ietf-rtcweb-security-arch"/>.  With peer authentication, each
        user is able to be sure that:
        <list style="symbols">
          <t>
            the content they are generating is only accessible to the authenticated peer; and
          </t>
          <t>
            the content they are receiving can be attributed solely to the authenticated peer.
          </t>
        </list>
      </t>
      <t>
        On the originating end of a communications session, this guarantee is easy to provide.  A
        web site is able to provide instructions for session setup that allow the browser to
        protect content from the site, and to restrict where content is delivered based on identity.
      </t>
      <t>
        On the receiving side, this is more complicated.  Since there is a desire to enable use
        cases where sites do have access to content that is received, there is a need for a signal
        of some form to distinguish the cases.
      </t>
      <t>
        It is possible to use the WebRTC signaling channel for this purpose, but only with
        restrictions.  The signaling channel is considered untrustworthy, so additional protection
        would be required to ensure that any indicators could not be erased or re-attributed to
        other keying material.  Furthermore, this would also require protection against replay.
        Prohibiting key reuse between confidential and non-confidential sessions would suffice for
        this purpose, though this is undesirable for other reasons.
      </t>

      <section title="Authenticated Content Promise">
        <t>
          This document describes a <xref target="RFC5246">Transport Layer Security (TLS)</xref>
          extension, which, if negotiated, establishes a session as being confidential.  Peers that
          negotiate this extension promise that:
          <list style="symbols">
            <t>
              Any content that is written to or read from the connection MUST be protected from
              modification by entities other than the one that is authenticated (i.e., the user).
            </t>
            <t>
              Any content that is written to or read from the connection MUST NOT be recorded or
              forwarded to any entity other than the one that is authenticated.
            </t>
          </list>
        </t>
        <t>
          In addition to establishing an authenticated channel for communications, this provides a
          key advantage over signaling-based methods for ensuring privacy.  Key continuity is
          possible, which allows clients to operate without identity providers and still have a
          stable basis for establishing continuity of identity with peers.
        </t>
      </section>

      <section title="Conventions and Terminology" anchor="terminology">
       <t>
         At times, this document falls back on shorthands for establishing interoperability
         requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY".  These
         terms are defined in <xref target="RFC2119"/>.
       </t>
      </section>
    </section>

    <section title="Authenticated Content Promise" anchor="acp">
      <t>
        A new extension type (<spanx style="verb">authenticated_content_promise(TBD)</spanx>) is
        defined.  If this extension is negotiated, both client and server are bound by a promise to
        protect content.
      </t>
      <figure><artwork><![CDATA[
enum {
    authenticated_content_promise(TBD), (65535)
} ExtensionType;
]]></artwork></figure>
      <t>
        The <spanx style="verb">extension_data</spanx> field of this extension MUST be empty.
      </t>
   </section>

    <section anchor="security" title="Security Considerations">
      <t>
        Endpoints need to take care to avoid rendering of authenticated content alongside other
        content in a way that could cause user confusion equivalent to the effect of modifying
        content.  For instance, unauthenticated audio could be played at higher volume levels than
        authenticated audio, potentially misleading users about what sounds can be attributed to
        each.
      </t>
      <t>
        This looks a little like digital rights management (DRM), but it really doesn't promise to
        protect content to the degree required by DRM schemes.  It relies solely on users and their
        trust each other (and their user agents, operating system and hardware).  Nothing in this
        mechanism stops a compromised end system from modifying or eavesdropping on communications,
        from information being overhead or seen by people nearby, or from any action taken on the
        part of the authentiated entities, such as screen recording.
      </t>
      <t>
        A little care is needed to avoid side channels, some of which are quite obvious.  For
        example, even with echo cancellation, audio played over speakers can be picked up by nearby
        microphones; video playback might be observable in a mirror.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        IANA has allocated a TLS extension code point of (TBD) for this extension.
      </t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>
        Eric Rescorla helped identify the problem and formulate this mechanism.
      </t>
    </section>

    <!--
        <appendix title="Change Log">
        <t>[[The RFC Editor is requested to remove this section at publication.]]</t>
        <t>Changes since -0-1:
        <list style="symbols">
        <t>Document created.</t>
        </list>
        </t>
        </appendix>
    -->
  </middle>

  <back>

    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
    </references>
    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security-arch.xml"?>
    </references>
  </back>
</rfc>