<?xmlversion="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" ?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtcweb-alpn-04" indexInclude="true" ipr="trust200902"docName="draft-ietf-rtcweb-alpn-04">number="8833" prepTime="2021-01-16T21:51:18" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn-04" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8833" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="ALPN forWebRTC"> Application LayerWebRTC">Application-Layer Protocol Negotiation (ALPN) forWeb Real-Time Communications (WebRTC) </title>WebRTC</title> <seriesInfo name="RFC" value="8833" stream="IETF"/> <author initials="M." surname="Thomson" fullname="Martin Thomson"><organization>Mozilla</organization><organization showOnFrontPage="true">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> <dateyear="2016"/> <area>RAI</area> <workgroup>RTCWEB</workgroup> <keyword>Internet-Draft</keyword>month="01" year="2021"/> <keyword>ALPN</keyword> <keyword>Protocol</keyword> <keyword>Identifier</keyword><abstract> <t><abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"> This document specifies twoApplication LayerApplication-Layer Protocol Negotiation (ALPN) labels for use with Web Real-TimeCommunicationsCommunication (WebRTC). The "webrtc" label identifies regularWebRTC communications:WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels usingSCTPthe 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> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8833" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2"> <li pn="section-toc.1-1.1.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-alpn-labels-for-webrtc">ALPN Labels for WebRTC</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-media-confidentiality">Media Confidentiality</xref></t> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="intro"title="Introduction"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1"> <xreftarget="I-D.ietf-rtcweb-overview">Webtarget="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825">Web Real-TimeCommunicationsCommunication (WebRTC)</xref> uses <xreftarget="RFC6347">Datagramtarget="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347">Datagram Transport Layer Security (DTLS)</xref> to secure all peer-to-peer communications. </t><t><t indent="0" pn="section-1-2"> Identifying WebRTC protocol usage with <xreftarget="RFC7301">Application Layertarget="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301">Application-Layer Protocol Negotiation (ALPN)</xref> enables an endpoint to positively identify WebRTC uses and distinguish them from other DTLS uses. </t><t><t indent="0" pn="section-1-3"> 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> <sectiontitle="Conventions and Terminology" anchor="terminology"> <t>anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-conventions">Conventions</name> <t indent="0" pn="section-1.1-1"> 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 <xreftarget="RFC2119"/>.target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="ALPNnumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-alpn-labels-for-webrtc">ALPN Labels forWebRTC"> <t>WebRTC</name> <t indent="0" pn="section-2-1"> The following identifiers are defined for use in ALPN:<list style="hanging"> <t hangText="webrtc:"></t> <dl newline="false" spacing="normal" indent="3" pn="section-2-2"> <dt pn="section-2-2.1">webrtc:</dt> <dd pn="section-2-2.2"> The DTLS session is used to establish keys for the Secure Real-time Transport Protocol (SRTP)--- known as DTLS-SRTP--- as described in <xreftarget="RFC5764"/>.target="RFC5764" format="default" sectionFormat="of" derivedContent="RFC5764"/>. The DTLS record layer is used for <xreftarget="I-D.ietf-rtcweb-data-channel">WebRTCtarget="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831">WebRTC data channels</xref>.</t> <t hangText="c-webrtc:"></dd> <dt pn="section-2-2.3">c-webrtc:</dt> <dd pn="section-2-2.4"> The DTLS session is used for confidentialWebRTC communications,WebRTC, where peers agree to maintain the confidentiality of the media, as described in <xreftarget="confidentiality"/>.target="confidentiality" format="default" sectionFormat="of" derivedContent="Section 3"/>. 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> <t></dd> </dl> <t indent="0" pn="section-2-3"> 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 <xreftarget="RFC4960">Streamtarget="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960">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 <xreftarget="RFC5245">Interactive Communicationtarget="RFC8445" format="default" sectionFormat="of" derivedContent="RFC8445">Interactive Connectivity Establishment (ICE)</xref> to establishtheUDP flow, but this is not covered by the identifier. </t><t><t indent="0" pn="section-2-4"> A more thorough definition of what WebRTCcommunications entailentails is included in <xreftarget="I-D.ietf-rtcweb-transports"/>.target="RFC8835" format="default" sectionFormat="of" derivedContent="RFC8835"/>. </t><t><t indent="0" pn="section-2-5"> 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><t indent="0" pn="section-2-6"> A peer that is not aware of whether it needs to request confidentiality can use either identifier. A peer in the client roleMUST<bcp14>MUST</bcp14> offer both identifiers if it is not aware of a need for confidentiality. A peer in the server roleSHOULD<bcp14>SHOULD</bcp14> select<spanx style="verb">webrtc</spanx><tt>webrtc</tt> if it does not prefer either. </t><t><t indent="0" pn="section-2-7"> An endpoint that requires media confidentiality might negotiate a session with a peer that does not support this specification.Endpoint MUSTAn 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 peerMUST 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> <sectiontitle="Media Confidentiality" anchor="confidentiality"> <t>anchor="confidentiality" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-media-confidentiality">Media Confidentiality</name> <t indent="0" pn="section-3-1"> Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media <xreftarget="I-D.ietf-rtcweb-security-arch"/>.target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>. 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 asession,session without having access to the media that is exchanged in the session. </t><t><t indent="0" pn="section-3-2"> 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><t indent="0" pn="section-3-3"> A browser is required to enforce this confidentiality protection using isolation controls similar to those used in content cross-origin protections (see<eref target="http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin">Section 5.3</eref>the "Origin" section of <xreftarget="HTML5"/>).target="HTML5" format="default" sectionFormat="of" derivedContent="HTML5"/>). These protections ensure that media is protected fromapplications. Applicationsapplications, 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> identifierMUST<bcp14>MUST</bcp14> only be displayed to users. </t><t><t indent="0" pn="section-3-4"> 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 exclusivelybrowser-browser oruser-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><t indent="0" pn="section-3-5"> This mechanism explicitly does not define a specific authentication method; a WebRTC endpoint that accepts a session with this ALPN identifierMUST<bcp14>MUST</bcp14> respect confidentiality no matter what identity is attributed to a peer. </t><t><t indent="0" pn="section-3-6"> 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"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-4-1"> Confidential communicationsdependsdepend on more than just an agreement from browsers. </t><t><t indent="0" pn="section-4-2"> Information is not confidential if it is displayed tothose otherothers thantofor whom it is intended. <xreftarget="I-D.ietf-rtcweb-security-arch">Peertarget="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827">Peer authentication</xref> is necessary to ensure that data is only sent to the intended peer. </t><t><t indent="0" pn="section-4-3"> 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 recordingscreen-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><t indent="0" pn="section-4-4"> 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><t indent="0" pn="section-4-5"> On a shared computing platform like a browser, other entities with access to that platform (i.e., webapplications),applications) might be able to access information that would compromise the confidentiality of communications. ImplementationsMAY<bcp14>MAY</bcp14> choose to limit concurrent access to input devices during confidential communications sessions. </t><t><t indent="0" pn="section-4-6"> 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"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-5-1"> The following two entriesarehave been added to the"Application Layer"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by <xreftarget="RFC7301"/>: <list style="hanging"> <t hangText="webrtc:"> <vspace blankLines="1"/>target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301"/>: </t> <dl newline="true" spacing="normal" indent="3" pn="section-5-2"> <dt pn="section-5-2.1">webrtc:</dt> <dd pn="section-5-2.2"> <t indent="0" pn="section-5-2.2.1"> 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" indent="3" pn="section-5-2.2.2"> <dt pn="section-5-2.2.2.1">Protocol:</dt> <dd pn="section-5-2.2.2.2">WebRTC Media andData</t> <t hangText="Identification Sequence:">0x77Data</dd> <dt pn="section-5-2.2.2.3">Identification Sequence:</dt> <dd pn="section-5-2.2.2.4">0x77 0x65 0x62 0x72 0x74 0x63("webrtc")</t>("webrtc")</dd> <dt pn="section-5-2.2.2.5">Specification:</dt> <dd pn="section-5-2.2.2.6">RFC 8833 (this document)</dd> </dl> </dd> <dt pn="section-5-2.3">c-webrtc:</dt> <dd pn="section-5-2.4"> <thangText="Specification:">This document (RFCXXXX)</t> </list> </t> <t hangText="c-webrtc:"> <vspace blankLines="1"/>indent="0" pn="section-5-2.4.1"> The<spanx style="verb">c-webrtc</spanx><tt>c-webrtc</tt> label identifies WebRTCcommunicationswith a promise to protect media confidentiality:<list style="hanging"> <t hangText="Protocol:">Confidential</t> <dl newline="false" spacing="normal" indent="3" pn="section-5-2.4.2"> <dt pn="section-5-2.4.2.1">Protocol:</dt> <dd pn="section-5-2.4.2.2">Confidential WebRTC Media andData</t> <t hangText="Identification Sequence:">0x63Data</dd> <dt pn="section-5-2.4.2.3">Identification Sequence:</dt> <dd pn="section-5-2.4.2.4">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 pn="section-5-2.4.2.5">Specification:</dt> <dd pn="section-5-2.4.2.6">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> <referencestitle="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>pn="section-6"> <name slugifiedName="name-references">References</name> <referencestitle="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"?>pn="section-6.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121217/">anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front><title> HTML 5 </title> <author initials="R." surname="Berjon" fullname="Robin Berjon"/> <author initials="T." surname="Leithead" fullname="Travis Leithead"/> <author initials="E." surname="Doyle Navara" fullname="Erika Doyle Navara"/> <author initials="E." surname="O'Connor" fullname="Edward O'Connor"/><title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S."surname="Pfeiffer" fullname="Silvia Pfeiffer"/>surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <dateyear="2010" month="August"/> </front> <seriesInfo name="CR" value="CR-html5-20121217"/> </reference> </references>year="1997" month="March"/> <abstract> <t indent="0">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="RFC5764" target="https://www.rfc-editor.org/info/rfc5764" quoteTitle="true" derivedAnchor="RFC5764"> <front> <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title> <author initials="D." surname="McGrew" fullname="D. McGrew"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization showOnFrontPage="true"/> </author> <date year="2010" month="May"/> <abstract> <t indent="0">This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5764"/> <seriesInfo name="DOI" value="10.17487/RFC5764"/> </reference> <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347"> <front> <title>Datagram Transport Layer Security Version 1.2</title> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization showOnFrontPage="true"/> </author> <author initials="N." surname="Modadugu" fullname="N. Modadugu"> <organization showOnFrontPage="true"/> </author> <date year="2012" month="January"/> <abstract> <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6347"/> <seriesInfo name="DOI" value="10.17487/RFC6347"/> </reference> <reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7301" quoteTitle="true" derivedAnchor="RFC7301"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <author initials="S." surname="Friedl" fullname="S. Friedl"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Popov" fullname="A. Popov"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Langley" fullname="A. Langley"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Stephan" fullname="E. Stephan"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="July"/> <abstract> <t indent="0">This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t> </abstract> </front> <seriesInfo name="RFC" value="7301"/> <seriesInfo name="DOI" value="10.17487/RFC7301"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827" quoteTitle="true" derivedAnchor="RFC8827"> <front> <title>WebRTC Security Architecture</title> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8827"/> <seriesInfo name="DOI" value="10.17487/RFC8827"/> </reference> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831" quoteTitle="true" derivedAnchor="RFC8831"> <front> <title>WebRTC Data Channels</title> <author initials="R" surname="Jesup" fullname="Randell Jesup"> <organization showOnFrontPage="true"/> </author> <author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <organization showOnFrontPage="true"/> </author> <author initials="M" surname="Tüxen" fullname="Michael Tüxen"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8831"/> <seriesInfo name="DOI" value="10.17487/RFC8831"/> </reference> </references> <references pn="section-6.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="HTML5" target="https://html.spec.whatwg.org/#origin" quoteTitle="true" derivedAnchor="HTML5"> <front> <title>HTML - Living Standard</title> <author> <organization showOnFrontPage="true">WHATWG</organization> </author> <date month="January" year="2021"/> </front> <refcontent>Section 7.5</refcontent> </reference> <reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4960" quoteTitle="true" derivedAnchor="RFC4960"> <front> <title>Stream Control Transmission Protocol</title> <author initials="R." surname="Stewart" fullname="R. Stewart" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t> <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:</t> <t indent="0">-- acknowledged error-free non-duplicated transfer of user data,</t> <t indent="0">-- data fragmentation to conform to discovered path MTU size,</t> <t indent="0">-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t> <t indent="0">-- optional bundling of multiple user messages into a single SCTP packet, and</t> <t indent="0">-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t> <t indent="0"> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4960"/> <seriesInfo name="DOI" value="10.17487/RFC4960"/> </reference> <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" quoteTitle="true" derivedAnchor="RFC8445"> <front> <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title> <author initials="A." surname="Keranen" fullname="A. Keranen"> <organization showOnFrontPage="true"/> </author> <author initials="C." surname="Holmberg" fullname="C. Holmberg"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Rosenberg" fullname="J. Rosenberg"> <organization showOnFrontPage="true"/> </author> <date year="2018" month="July"/> <abstract> <t indent="0">This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t> <t indent="0">This document obsoletes RFC 5245.</t> </abstract> </front> <seriesInfo name="RFC" value="8445"/> <seriesInfo name="DOI" value="10.17487/RFC8445"/> </reference> <reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825"> <front> <title>Overview: Real-Time Protocols for Browser-Based Applications</title> <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8825"/> <seriesInfo name="DOI" value="10.17487/RFC8825"/> </reference> <reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835" quoteTitle="true" derivedAnchor="RFC8835"> <front> <title>Transports for WebRTC</title> <author initials="H." surname="Alvestrand" fullname="Harald Alvestrand"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8835"/> <seriesInfo name="DOI" value="10.17487/RFC8835"/> </reference> </references> </references> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a"> <name slugifiedName="name-authors-address">Author's Address</name> <author initials="M." surname="Thomson" fullname="Martin Thomson"> <organization showOnFrontPage="true">Mozilla</organization> <address> <postal/> <email>martin.thomson@gmail.com</email> </address> </author> </section> </back> </rfc>