<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> version='1.0' encoding='utf-8'?>
<!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" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8833"
     docName="draft-ietf-rtcweb-alpn-04" category="std"
     submissionType="IETF" consensus="yes" ipr="trust200902" docName="draft-ietf-rtcweb-alpn-04"> obsoletes=""
     updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
     sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.44.0 -->
  <front>
    <title abbrev="ALPN for WebRTC">
      Application Layer
      Application-Layer Protocol Negotiation (ALPN) for Web Real-Time Communications (WebRTC) WebRTC
    </title>
    <seriesInfo name="RFC" value="8833"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>331 E Evelyn Street</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>US</country>
        </postal>
        <postal/>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <date year="2016"/>
    <area>RAI</area> month="June" year="2020"/>

    <area>ART</area>
    <workgroup>RTCWEB</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>ALPN</keyword>
    <keyword>Protocol</keyword>
    <keyword>Identifier</keyword>

    <abstract>
      <t>
        This document specifies two Application Layer Application-Layer Protocol Negotiation (ALPN) labels for use
        with Web Real-Time Communications Communication (WebRTC).  The "webrtc" label identifies regular WebRTC
        communications: WebRTC:
        a DTLS session that is used to establish keys for the Secure Real-time Transport
        Protocol (SRTP) or to establish data channels using SCTP the Stream Control
	Transmission Protocol (SCTP) over DTLS.  The "c-webrtc" label
        describes the same protocol, but the peers also agree to maintain the confidentiality of the
        media by not sharing it with other applications.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        <xref target="I-D.ietf-rtcweb-overview">Web target="RFC8825" format="default">Web Real-Time Communications Communication (WebRTC)</xref> uses
        <xref target="RFC6347">Datagram target="RFC6347" format="default">Datagram Transport Layer Security (DTLS)</xref> to secure all
        peer-to-peer communications.
      </t>
      <t>
        Identifying WebRTC protocol usage with <xref target="RFC7301">Application Layer target="RFC7301" format="default">Application-Layer Protocol
        Negotiation (ALPN)</xref> enables an endpoint to positively identify WebRTC uses and
        distinguish them from other DTLS uses.
      </t>
      <t>
        Different WebRTC uses can be advertised and behavior can be constrained to what is
        appropriate to a given use.  In particular, this allows for the identification of sessions
        that require confidentiality protection from the application that manages the signaling for
        the session.
      </t>
      <section title="Conventions and Terminology" anchor="terminology"> anchor="terminology" numbered="true" toc="default">
        <name>Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
          NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC2119"/>. target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section title="ALPN numbered="true" toc="default">
      <name>ALPN Labels for WebRTC"> WebRTC</name>
      <t>
        The following identifiers are defined for use in ALPN:
        <list style="hanging">
          <t hangText="webrtc:">
      </t>
      <dl newline="false" spacing="normal">
        <dt>webrtc:</dt>
        <dd>
            The DTLS session is used to establish keys for the Secure Real-time Transport Protocol
            (SRTP) - -- known as DTLS-SRTP - -- as described in <xref target="RFC5764"/>. target="RFC5764" format="default"/>.  The DTLS record
            layer is used for <xref target="I-D.ietf-rtcweb-data-channel">WebRTC target="RFC8831" format="default">WebRTC data
            channels</xref>.
          </t>
          <t hangText="c-webrtc:">
          </dd>
        <dt>c-webrtc:</dt>
        <dd>
            The DTLS session is used for confidential WebRTC communications, WebRTC, where peers agree to
            maintain the confidentiality of the media, as described in <xref
            target="confidentiality"/>. target="confidentiality" format="default"/>. The confidentiality protections ensure that media is
            protected from other applications, but the confidentiality protections do not extend to
            messages on data channels.
          </t>
        </list>
      </t>
          </dd>
      </dl>
      <t>
        Both identifiers describe the same basic protocol: a DTLS session that is used to provide
        keys for an SRTP session in combination with WebRTC data channels.  Either SRTP or data
        channels could be absent.  The data channels send the <xref target="RFC4960">Stream target="RFC4960" format="default">Stream Control
        Transmission Protocol (SCTP)</xref> over the DTLS record layer, which can be multiplexed
        with SRTP on the same UDP flow.  WebRTC requires the use of <xref
        target="RFC5245">Interactive Communication target="RFC8445" format="default">Interactive Connectivity Establishment (ICE)</xref> to establish the UDP
        flow, but this is not covered by the identifier.
      </t>
      <t>
        A more thorough definition of what WebRTC communications entail entails is included in <xref
        target="I-D.ietf-rtcweb-transports"/>. target="RFC8835" format="default"/>.
      </t>
      <t>
        There is no functional difference between the identifiers except that an endpoint
        negotiating <spanx style="verb">c-webrtc</spanx> <tt>c-webrtc</tt> makes a promise to preserve the
        confidentiality of the media it receives.
      </t>
      <t>
        A peer that is not aware of whether it needs to request confidentiality can use either
        identifier.  A peer in the client role MUST <bcp14>MUST</bcp14> offer both identifiers if it is not aware of a
        need for confidentiality. A peer in the server role SHOULD <bcp14>SHOULD</bcp14> select <spanx
        style="verb">webrtc</spanx> <tt>webrtc</tt> if it does not prefer either.
      </t>
      <t>
        An endpoint that requires media confidentiality might negotiate a session with a peer that
        does not support this specification.  Endpoint MUST  An endpoint <bcp14>MUST</bcp14> abort a session if it requires
        confidentiality but does not successfully negotiate <spanx style="verb">c-webrtc</spanx>. <tt>c-webrtc</tt>.  A
        peer that is willing to accept <spanx style="verb">webrtc</spanx> SHOULD <tt>webrtc</tt> <bcp14>SHOULD</bcp14> assume that a peer
        that does not support this specification has negotiated <spanx style="verb">webrtc</spanx> <tt>webrtc</tt>
        unless signaling provides other information; however, a peer MUST NOT <bcp14>MUST NOT</bcp14> assume that <spanx
        style="verb">c-webrtc</spanx> <tt>c-webrtc</tt> has been negotiated unless explicitly negotiated.
      </t>
    </section>
    <section title="Media Confidentiality" anchor="confidentiality"> anchor="confidentiality" numbered="true" toc="default">
      <name>Media Confidentiality</name>
      <t>
        Private communications in WebRTC depend on separating control (i.e., signaling) capabilities
        and access to media <xref target="I-D.ietf-rtcweb-security-arch"/>. target="RFC8827" format="default"/>.  In this way, an
        application can establish a session that is end-to-end confidential, where the ends in
        question are user agents (or browsers) and not the signaling application.  This allows an
        application to manage signaling for a session, session without having access to the media that is
        exchanged in the session.
      </t>
      <t>
        Without some form of indication that is securely bound to the session, a WebRTC endpoint is
        unable to properly distinguish between a session that requires this confidentiality
        protection and one that does not.  The ALPN identifier provides that signal.
      </t>
      <t>
        A browser is required to enforce this confidentiality protection using isolation controls
        similar to those used in content cross-origin protections
<!-- (see <xref
	target="HTML5" relative="#origin" section="5.3"
	format="default"/>). -->
(see <eref
        target="http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin">Section 5.3</eref> the "Origin" section of <xref target="HTML5"/>).
  These protections ensure that media is protected from
        applications.  Applications
        applications, which are not able to read or modify the contents of a protected flow
        of media.  Media that is produced from a session using the <spanx
        style="verb">c-webrtc</spanx> <tt>c-webrtc</tt> identifier MUST <bcp14>MUST</bcp14> only be displayed to users.
      </t>
      <t>
        The promise to apply confidentiality protections do not apply to data that is sent using
        data channels.  Confidential data depends on having both data sources and consumers that are
        exclusively browser- browser or user-based. user based.  No mechanisms currently exist to take advantage of data
        confidentiality, though some use cases suggest that this could be useful, for example,
        confidential peer-to-peer file transfer.  Alternative labels might be
	provided in the future to support these use cases.
      </t>
      <t>
        This mechanism explicitly does not define a specific authentication method; a WebRTC
        endpoint that accepts a session with this ALPN identifier MUST <bcp14>MUST</bcp14> respect confidentiality no
        matter what identity is attributed to a peer.
      </t>
      <t>
        RTP middleboxes and entities that forward media or data cannot promise to maintain
        confidentiality.  Any entity that forwards content, or records content for later access by
        entities other than the authenticated peer, MUST NOT <bcp14>MUST NOT</bcp14> offer or accept a session with the
        <spanx style="verb">c-webrtc</spanx>
        <tt>c-webrtc</tt> identifier.
      </t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        Confidential communications depends depend on more than just an agreement from browsers.
      </t>
      <t>
        Information is not confidential if it is displayed to those other others than to for whom it is
        intended.  <xref target="I-D.ietf-rtcweb-security-arch">Peer target="RFC8827" format="default">Peer authentication</xref> is
        necessary to ensure that data is only sent to the intended peer.
      </t>
      <t>
        This is not a digital rights management mechanism. A user is not prevented from using other
        mechanisms to record or forward media.  This means that (for example) screen recording screen-recording
        devices, tape recorders, portable cameras, or a cunning arrangement of mirrors could
        variously be used to record or redistribute media once delivered.  Similarly, if media is
        visible or audible (or otherwise accessible) to others in the vicinity, there are no
        technical measures that protect the confidentiality of that media.
      </t>
      <t>
        The only guarantee provided by this mechanism and the browser that implements it is that the
        media was delivered to the user that was authenticated.  Individual users will still need to
        make a judgment about how their peer intends to respect the confidentiality of any
        information provided.
      </t>
      <t>
        On a shared computing platform like a browser, other entities with access to that platform
        (i.e., web applications), applications) might be able to access information that would compromise the
        confidentiality of communications.  Implementations MAY <bcp14>MAY</bcp14> choose to limit concurrent access to
        input devices during confidential communications sessions.
      </t>
      <t>
        For instance, another application that is able to access a microphone might be able to
        sample confidential audio that is playing through speakers.  This is true even if acoustic
        echo cancellation, which attempts to prevent this from happening, is used.  Similarly, an
        application with access to a video camera might be able to use reflections to obtain all or
        part of a confidential video stream.
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        The following two entries are have been added to the "Application Layer "TLS Application-Layer
	Protocol Negotiation (ALPN) Protocol IDs" registry established by
	<xref target="RFC7301"/>:
        <list style="hanging">
          <t hangText="webrtc:">
            <vspace blankLines="1"/> target="RFC7301" format="default"/>:
      </t>
      <dl newline="true" spacing="normal">
        <dt>webrtc:</dt>
        <dd>
          <t>
            The <spanx style="verb">webrtc</spanx> <tt>webrtc</tt> label identifies mixed media and data
            communications using SRTP and data channels:
            <list style="hanging">
              <t hangText="Protocol:">WebRTC
          </t>
          <dl newline="false" spacing="normal">
            <dt>Protocol:</dt>
            <dd>WebRTC Media and Data</t>
              <t hangText="Identification Sequence:">0x77 Data</dd>
            <dt>Identification Sequence:</dt>
            <dd>0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")</t>
              <t hangText="Specification:">This document (RFCXXXX)</t>
            </list>
          </t>
          <t hangText="c-webrtc:">
            <vspace blankLines="1"/> ("webrtc")</dd>
            <dt>Specification:</dt>
            <dd>RFC 8833 (this document)</dd>
          </dl>
        </dd>
        <dt>c-webrtc:</dt>
        <dd>
          <t>
            The <spanx style="verb">c-webrtc</spanx> <tt>c-webrtc</tt> label identifies WebRTC
            communications
            with a promise to protect media confidentiality:
            <list style="hanging">
              <t hangText="Protocol:">Confidential
          </t>
          <dl newline="false" spacing="normal">
            <dt>Protocol:</dt>
            <dd>Confidential WebRTC Media and Data</t>
              <t hangText="Identification Sequence:">0x63 Data</dd>
            <dt>Identification Sequence:</dt>
            <dd>0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63
              ("c-webrtc")</t>
              <t hangText="Specification:">This document (RFCXXXX)</t>
            </list>
          </t>
        </list>
      </t>
              ("c-webrtc")</dd>
            <dt>Specification:</dt>
            <dd>RFC 8833 (this document)</dd>
          </dl>
        </dd>
      </dl>
    </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.6347.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7301.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security-arch.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-channel.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml"?>
      <?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-transports.xml"?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>

 <!--draft-ietf-rtcweb-security-arch: 8827 -->
 <reference anchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121217/"> anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
 <front>
          <title>
            HTML 5
          </title>
 <title>WebRTC Security Architecture</title>
 <seriesInfo name="RFC" value="8827"/>
 <seriesInfo name="DOI" value="10.17487/RFC8827"/>
 <author initials="R." surname="Berjon" fullname="Robin Berjon"/> initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
   <organization/>
 </author>
 <date month='June' year='2020'/>
 </front>
 </reference>

<!-- draft-ietf-rtcweb-data-channel: 8831 -->
<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front>
<title>WebRTC Data Channels</title>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
<author initials="T." surname="Leithead" fullname="Travis Leithead"/> initials="R." surname="Jesup" fullname="Randell Jesup">
  <organization/>
</author>
<author initials="E." surname="Doyle Navara" fullname="Erika Doyle Navara"/> initials="S." surname="Loreto" fullname="Salvatore Loreto">
  <organization/>
</author>
<author initials="E." surname="O'Connor" fullname="Edward O'Connor"/> initials="M." surname="Tüxen" fullname="Michael Tüxen">
  <organization/>
</author>
<date month='June' year='2020'/>
</front>
</reference>

</references>
<references>
  <name>Informative References</name>
  <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
  <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
  <front>
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
  <seriesInfo name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>
    <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/> initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    </author>
    <date year="2010" month="August"/> month="June" year="2020" />
  </front>
</reference>

<!-- draft-ietf-rtcweb-transports-17: 8835 -->
<reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835">
  <front>
    <title>Transports for WebRTC</title>
  <seriesInfo name="CR" value="CR-html5-20121217"/> name="RFC" value="8835" />
  <seriesInfo name="DOI" value="10.17487/RFC8835"/>
    <author initials="H." surname="Alvestrand" fullname="Harald Alvestrand">
      <organization />
    </author>
    <date month="June" year="2020" />
  </front>
</reference>

      <reference anchor="HTML5" target="https://html.spec.whatwg.org/#origin">
          <front>
            <title>HTML - Living Standard</title>
           <author>
            <organization>WHATWG</organization>
           </author>
            <date month="June" year="2020" />
          </front>
         <refcontent>Section 7.5</refcontent>
        </reference>
      </references>
    </references>
  </back>
</rfc>