Diff: rfc8833xml2.original.xml

	rfc8833xml2.original.xml	rfc8833.xml

	<?xml version="1.0"?>	<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	nsus="true" docName="draft-ietf-rtcweb-alpn-04" indexInclude="true" ipr="trust20
		0902" number="8833" prepTime="2021-01-16T21:51:18" scripts="Common,Latin" sortRe
	<?rfc strict="yes" ?>	fs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xm
	<?rfc toc="yes"?>	l:lang="en">
	<?rfc tocdepth="4"?>	<link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn-04" rel="p
	<?rfc symrefs="yes"?>	rev"/>
	<?rfc sortrefs="yes" ?>	<link href="https://dx.doi.org/10.17487/rfc8833" rel="alternate"/>
	<?rfc compact="yes" ?>	<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc subcompact="no" ?>

	<rfc category="std" ipr="trust200902" docName="draft-ietf-rtcweb-alpn-04">
	<front>	<front>

	<title abbrev="ALPN for WebRTC">	<title abbrev="ALPN for WebRTC">Application-Layer Protocol Negotiation (ALPN
	Application Layer Protocol Negotiation for Web Real-Time Communications (W	) for WebRTC</title>
	ebRTC)	<seriesInfo name="RFC" value="8833" stream="IETF"/>
	</title>

	<author initials="M." surname="Thomson" fullname="Martin Thomson">	<author initials="M." surname="Thomson" fullname="Martin Thomson">

	<organization>Mozilla</organization>	<organization showOnFrontPage="true">Mozilla</organization>
	<address>	<address>

	<postal>	<postal/>
	<street>331 E Evelyn Street</street>
	<city>Mountain View</city>
	<region>CA</region>
	<code>94041</code>
	<country>US</country>
	</postal>

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

		<date month="01" year="2021"/>
	<date year="2016"/>
	<area>RAI</area>
	<workgroup>RTCWEB</workgroup>
	<keyword>Internet-Draft</keyword>
	<keyword>ALPN</keyword>	<keyword>ALPN</keyword>
	<keyword>Protocol</keyword>	<keyword>Protocol</keyword>
	<keyword>Identifier</keyword>	<keyword>Identifier</keyword>

		<abstract pn="section-abstract">
	<abstract>	<t indent="0" pn="section-abstract-1">
	<t>	This document specifies two Application-Layer Protocol Negotiation (ALPN
	This document specifies two Application Layer Protocol Negotiation (ALPN	) labels for use
	) labels for use	with Web Real-Time Communication (WebRTC). The "webrtc" label identifie
	with Web Real-Time Communications (WebRTC). The "webrtc" label identifi	s regular WebRTC:
	es regular WebRTC	a DTLS session that is used to establish keys for the Secure Real-time T
	communications: a DTLS session that is used establish keys for Secure Re	ransport
	al-time Transport	Protocol (SRTP) or to establish data channels using the Stream Control
	Protocol (SRTP) or to establish data channels using SCTP over DTLS. The	Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label
	"c-webrtc" label
	describes the same protocol, but the peers also agree to maintain the co nfidentiality of the	describes the same protocol, but the peers also agree to maintain the co nfidentiality of the
	media by not sharing it with other applications.	media by not sharing it with other applications.
	</t>	</t>
	</abstract>	</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="non
		e"/>.
		</t>
		</section>
		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
		ude" 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" p
		n="section-toc.1">
		<name slugifiedName="name-table-of-contents">Table of Contents</name>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
		c.1-1">
		<li pn="section-toc.1-1.1">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
		ivedContent="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="sectio
		n-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-co
		nventions">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 der
		ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-alpn-labels-fo
		r-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" form
		at="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-media-confidentiality">Media Confi
		dentiality</xref></t>
		</li>
		<li pn="section-toc.1-1.4">
		<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
		at="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" f
		ormat="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" form
		at="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
		ations</xref></t>
		</li>
		<li pn="section-toc.1-1.6">
		<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
		at="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-references">References</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derived
		Content="" 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 derived
		Content="" 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="" forma
		t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
		format="title" sectionFormat="of" target="name-authors-address">Author's Addres
		s</xref></t>
		</li>
		</ul>
		</section>
		</toc>
	</front>	</front>


	<middle>	<middle>

		<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
	<section anchor="intro" title="Introduction">	="section-1">
	<t>	<name slugifiedName="name-introduction">Introduction</name>
	<xref target="I-D.ietf-rtcweb-overview">Web Real-Time Communications (We	<t indent="0" pn="section-1-1">
	bRTC)</xref> uses	<xref target="RFC8825" format="default" sectionFormat="of" derivedConten
	<xref target="RFC6347">Datagram Transport Layer Security (DTLS)</xref> t	t="RFC8825">Web Real-Time Communication (WebRTC)</xref> uses
	o secure all	<xref target="RFC6347" format="default" sectionFormat="of" derivedConten
		t="RFC6347">Datagram Transport Layer Security (DTLS)</xref> to secure all
	peer-to-peer communications.	peer-to-peer communications.
	</t>	</t>

	<t>	<t indent="0" pn="section-1-2">
	Identifying WebRTC protocol usage with <xref target="RFC7301">Applicatio	Identifying WebRTC protocol usage with <xref target="RFC7301" format="de
	n Layer Protocol	fault" sectionFormat="of" derivedContent="RFC7301">Application-Layer Protocol
	Negotiation (ALPN)</xref> enables an endpoint to positively identify Web RTC uses and	Negotiation (ALPN)</xref> enables an endpoint to positively identify Web RTC uses and
	distinguish them from other DTLS uses.	distinguish them from other DTLS uses.
	</t>	</t>

	<t>	<t indent="0" pn="section-1-3">
	Different WebRTC uses can be advertised and behavior can be constrained to what is	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 identifi cation of sessions	appropriate to a given use. In particular, this allows for the identifi cation of sessions
	that require confidentiality protection from the application that manage s the signaling for	that require confidentiality protection from the application that manage s the signaling for
	the session.	the session.
	</t>	</t>

		<section anchor="terminology" numbered="true" toc="include" removeInRFC="f
	<section title="Conventions and Terminology" anchor="terminology">	alse" pn="section-1.1">
	<t>	<name slugifiedName="name-conventions">Conventions</name>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S	<t indent="0" pn="section-1.1-1">
	HOULD", "SHOULD	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
	document are to be	D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	interpreted as described in <xref target="RFC2119"/>.	OT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
		mat="of" derivedContent="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
	</t>	</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
	<section title="ALPN Labels for WebRTC">	<name slugifiedName="name-alpn-labels-for-webrtc">ALPN Labels for WebRTC</
	<t>	name>
		<t indent="0" pn="section-2-1">
	The following identifiers are defined for use in ALPN:	The following identifiers are defined for use in ALPN:

	<list style="hanging">	</t>
	<t hangText="webrtc:">	<dl newline="false" spacing="normal" indent="3" pn="section-2-2">
	The DTLS session is used to establish keys for Secure Real-time Tran	<dt pn="section-2-2.1">webrtc:</dt>
	sport Protocol	<dd pn="section-2-2.2">
	(SRTP) - known as DTLS-SRTP - as described in <xref target="RFC5764"	The DTLS session is used to establish keys for the Secure Real-time
	/>. The DTLS record	Transport Protocol
	layer is used for <xref target="I-D.ietf-rtcweb-data-channel">WebRTC	(SRTP) -- known as DTLS-SRTP -- as described in <xref target="RFC576
	data	4" format="default" sectionFormat="of" derivedContent="RFC5764"/>. The DTLS rec
		ord
		layer is used for <xref target="RFC8831" format="default" sectionFor
		mat="of" derivedContent="RFC8831">WebRTC data
	channels</xref>.	channels</xref>.

	</t>	</dd>
	<t hangText="c-webrtc:">	<dt pn="section-2-2.3">c-webrtc:</dt>
	The DTLS session is used for confidential WebRTC communications, whe	<dd pn="section-2-2.4">
	re peers agree to	The DTLS session is used for confidential WebRTC, where peers agree
	maintain the confidentiality of the media, as described in <xref	to
	target="confidentiality"/>. The confidentiality protections ensure t	maintain the confidentiality of the media, as described in <xref tar
	hat media is	get="confidentiality" format="default" sectionFormat="of" derivedContent="Sectio
		n 3"/>. The confidentiality protections ensure that media is
	protected from other applications, but the confidentiality protectio ns do not extend to	protected from other applications, but the confidentiality protectio ns do not extend to
	messages on data channels.	messages on data channels.

	</t>	</dd>
	</list>	</dl>
	</t>	<t indent="0" pn="section-2-3">
	<t>
	Both identifiers describe the same basic protocol: a DTLS session that i s used to provide	Both identifiers describe the same basic protocol: a DTLS session that i s used to provide
	keys for an SRTP session in combination with WebRTC data channels. Eith er SRTP or data	keys for an SRTP session in combination with WebRTC data channels. Eith er SRTP or data

	channels could be absent. The data channels send <xref target="RFC4960" >Stream Control	channels could be absent. The data channels send the <xref target="RFC4 960" format="default" sectionFormat="of" derivedContent="RFC4960">Stream Control
	Transmission Protocol (SCTP)</xref> over the DTLS record layer, which ca n be multiplexed	Transmission Protocol (SCTP)</xref> over the DTLS record layer, which ca n be multiplexed

	with SRTP on the same UDP flow. WebRTC requires the use of <xref	with SRTP on the same UDP flow. WebRTC requires the use of <xref target
	target="RFC5245">Interactive Communication Establishment (ICE)</xref> to	="RFC8445" format="default" sectionFormat="of" derivedContent="RFC8445">Interact
	establish the UDP	ive Connectivity Establishment (ICE)</xref> to establish UDP
	flow, but this is not covered by the identifier.	flow, but this is not covered by the identifier.
	</t>	</t>

	<t>	<t indent="0" pn="section-2-4">
	A more thorough definition of what WebRTC communications entail is inclu	A more thorough definition of what WebRTC entails is included in <xref t
	ded in <xref	arget="RFC8835" format="default" sectionFormat="of" derivedContent="RFC8835"/>.
	target="I-D.ietf-rtcweb-transports"/>.
	</t>	</t>

	<t>	<t indent="0" pn="section-2-5">
	There is no functional difference between the identifiers except that an endpoint	There is no functional difference between the identifiers except that an endpoint

	negotiating <spanx style="verb">c-webrtc</spanx> makes a promise to pres erve the	negotiating <tt>c-webrtc</tt> makes a promise to preserve the
	confidentiality of the media it receives.	confidentiality of the media it receives.
	</t>	</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	A peer that is not aware of whether it needs to request confidentiality can use either

	identifier. A peer in the client role MUST offer both identifiers if it	identifier. A peer in the client role <bcp14>MUST</bcp14> offer both id
	is not aware of a	entifiers if it is not aware of a
	need for confidentiality. A peer in the server role SHOULD select <spanx	need for confidentiality. A peer in the server role <bcp14>SHOULD</bcp14
	style="verb">webrtc</spanx> if it does not prefer either.	> select <tt>webrtc</tt> if it does not prefer either.
	</t>	</t>

	<t>	<t indent="0" pn="section-2-7">
	An endpoint that requires media confidentiality might negotiate a sessio n with a peer that	An endpoint that requires media confidentiality might negotiate a sessio n with a peer that

	does not support this specification. Endpoint MUST abort a session if i	does not support this specification. An endpoint <bcp14>MUST</bcp14> ab
	t requires	ort a session if it requires
	confidentiality but does not successfully negotiate <spanx style="verb">	confidentiality but does not successfully negotiate <tt>c-webrtc</tt>.
	c-webrtc</spanx>. A	A
	peer that is willing to accept <spanx style="verb">webrtc</spanx> SHOULD	peer that is willing to accept <tt>webrtc</tt> <bcp14>SHOULD</bcp14> ass
	assume that a peer	ume that a peer
	that does not support this specification has negotiated <spanx style="ve	that does not support this specification has negotiated <tt>webrtc</tt>
	rb">webrtc</spanx>	unless signaling provides other information; however, a peer <bcp14>MUST
	unless signaling provides other information; however, a peer MUST NOT as	NOT</bcp14> assume that <tt>c-webrtc</tt> has been negotiated unless explicitly
	sume that <spanx	negotiated.
	style="verb">c-webrtc</spanx> has been negotiated unless explicitly nego
	tiated.
	</t>	</t>
	</section>	</section>

		<section anchor="confidentiality" numbered="true" toc="include" removeInRFC=
	<section title="Media Confidentiality" anchor="confidentiality">	"false" pn="section-3">
	<t>	<name slugifiedName="name-media-confidentiality">Media Confidentiality</na
		me>
		<t indent="0" pn="section-3-1">
	Private communications in WebRTC depend on separating control (i.e., sig naling) capabilities	Private communications in WebRTC depend on separating control (i.e., sig naling) capabilities

	and access to media <xref target="I-D.ietf-rtcweb-security-arch"/>. In this way, an	and access to media <xref target="RFC8827" format="default" sectionForma t="of" derivedContent="RFC8827"/>. In this way, an
	application can establish a session that is end-to-end confidential, whe re the ends in	application can establish a session that is end-to-end confidential, whe re the ends in
	question are user agents (or browsers) and not the signaling application . This allows an	question are user agents (or browsers) and not the signaling application . This allows an

	application to manage signaling for a session, without having access to the media that is	application to manage signaling for a session without having access to t he media that is
	exchanged in the session.	exchanged in the session.
	</t>	</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	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 conf identiality	unable to properly distinguish between a session that requires this conf identiality
	protection and one that does not. The ALPN identifier provides that sig nal.	protection and one that does not. The ALPN identifier provides that sig nal.
	</t>	</t>

	<t>	<t indent="0" pn="section-3-3">
	A browser is required to enforce this confidentiality protection using i solation controls	A browser is required to enforce this confidentiality protection using i solation controls

	similar to those used in content cross-origin protections (see <eref	similar to those used in content cross-origin protections
	target="http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin	(see the "Origin" section of <xref target="HTML5" format="default" sectionFormat
	">Section 5.3</eref>	="of" derivedContent="HTML5"/>).
	of <xref target="HTML5"/>). These protections ensure that media is prot	These protections ensure that media is protected from
	ected from	applications, which are not able to read or modify the contents of a pro
	applications. Applications are not able to read or modify the contents	tected flow
	of a protected flow	of media. Media that is produced from a session using the <tt>c-webrtc<
	of media. Media that is produced from a session using the <spanx	/tt> identifier <bcp14>MUST</bcp14> only be displayed to users.
	style="verb">c-webrtc</spanx> identifier MUST only be displayed to users
	.
	</t>	</t>

	<t>	<t indent="0" pn="section-3-4">
	The promise to apply confidentiality protections do not apply to data th at is sent using	The promise to apply confidentiality protections do not apply to data th at is sent using
	data channels. Confidential data depends on having both data sources an d consumers that are	data channels. Confidential data depends on having both data sources an d consumers that are

	exclusively browser- or user-based. No mechanisms currently exist to ta ke advantage of data	exclusively browser or user based. No mechanisms currently exist to tak e advantage of data
	confidentiality, though some use cases suggest that this could be useful , for example,	confidentiality, though some use cases suggest that this could be useful , for example,

	confidential peer-to-peer file transfer. Alternative labels might be pr	confidential peer-to-peer file transfer. Alternative labels might be
	ovided in future to	provided in the future to support these use cases.
	support these use cases.
	</t>	</t>

	<t>	<t indent="0" pn="section-3-5">
	This mechanism explicitly does not define a specific authentication meth od; a WebRTC	This mechanism explicitly does not define a specific authentication meth od; a WebRTC

	endpoint that accepts a session with this ALPN identifier MUST respect c onfidentiality no	endpoint that accepts a session with this ALPN identifier <bcp14>MUST</b cp14> respect confidentiality no
	matter what identity is attributed to a peer.	matter what identity is attributed to a peer.
	</t>	</t>

	<t>	<t indent="0" pn="section-3-6">
	RTP middleboxes and entities that forward media or data cannot promise t o maintain	RTP middleboxes and entities that forward media or data cannot promise t o maintain
	confidentiality. Any entity that forwards content, or records content f or later access by	confidentiality. Any entity that forwards content, or records content f or later access by

	entities other than the authenticated peer, MUST NOT offer or accept a s	entities other than the authenticated peer, <bcp14>MUST NOT</bcp14> offe
	ession with the	r or accept a session with the
	<spanx style="verb">c-webrtc</spanx> identifier.	<tt>c-webrtc</tt> identifier.
	</t>	</t>

	</section>	</section>
		<section anchor="security" numbered="true" toc="include" removeInRFC="false"
	<section anchor="security" title="Security Considerations">	pn="section-4">
	<t>	<name slugifiedName="name-security-considerations">Security Considerations
	Confidential communications depends on more than just an agreement from	</name>
	browsers.	<t indent="0" pn="section-4-1">
		Confidential communications depend on more than just an agreement from b
		rowsers.
	</t>	</t>

	<t>	<t indent="0" pn="section-4-2">
	Information is not confidential if it is displayed to those other than t	Information is not confidential if it is displayed to others than for wh
	o whom it is	om it is
	intended. <xref target="I-D.ietf-rtcweb-security-arch">Peer authenticat	intended. <xref target="RFC8827" format="default" sectionFormat="of" de
	ion</xref> is	rivedContent="RFC8827">Peer authentication</xref> is
	necessary to ensure that data is only sent to the intended peer.	necessary to ensure that data is only sent to the intended peer.
	</t>	</t>

	<t>	<t indent="0" pn="section-4-3">
	This is not a digital rights management mechanism. A user is not preven	This is not a digital rights management mechanism. A user is not prevent
	ted from using other	ed from using other
	mechanisms to record or forward media. This means that (for example) sc	mechanisms to record or forward media. This means that (for example) sc
	reen recording	reen-recording
	devices, tape recorders, portable cameras, or a cunning arrangement of m irrors could	devices, tape recorders, portable cameras, or a cunning arrangement of m irrors could
	variously be used to record or redistribute media once delivered. Simil arly, if media is	variously be used to record or redistribute media once delivered. Simil arly, if media is
	visible or audible (or otherwise accessible) to others in the vicinity, there are no	visible or audible (or otherwise accessible) to others in the vicinity, there are no
	technical measures that protect the confidentiality of that media.	technical measures that protect the confidentiality of that media.
	</t>	</t>

	<t>	<t indent="0" pn="section-4-4">
	The only guarantee provided by this mechanism and the browser that imple ments it is that the	The only guarantee provided by this mechanism and the browser that imple ments it is that the
	media was delivered to the user that was authenticated. Individual user s will still need to	media was delivered to the user that was authenticated. Individual user s will still need to
	make a judgment about how their peer intends to respect the confidential ity of any	make a judgment about how their peer intends to respect the confidential ity of any
	information provided.	information provided.
	</t>	</t>

	<t>	<t indent="0" pn="section-4-5">
	On a shared computing platform like a browser, other entities with acces s to that platform	On a shared computing platform like a browser, other entities with acces s to that platform

	(i.e., web applications), might be able to access information that would	(i.e., web applications) might be able to access information that would
	compromise the	compromise the
	confidentiality of communications. Implementations MAY choose to limit	confidentiality of communications. Implementations <bcp14>MAY</bcp14> c
	concurrent access to	hoose to limit concurrent access to
	input devices during confidential communications sessions.	input devices during confidential communications sessions.
	</t>	</t>

	<t>	<t indent="0" pn="section-4-6">
	For instance, another application that is able to access a microphone mi ght be able to	For instance, another application that is able to access a microphone mi ght be able to
	sample confidential audio that is playing through speakers. This is tru e even if acoustic	sample confidential audio that is playing through speakers. This is tru e even if acoustic
	echo cancellation, which attempts to prevent this from happening, is use d. Similarly, an	echo cancellation, which attempts to prevent this from happening, is use d. Similarly, an
	application with access to a video camera might be able to use reflectio ns to obtain all or	application with access to a video camera might be able to use reflectio ns to obtain all or
	part of a confidential video stream.	part of a confidential video stream.
	</t>	</t>
	</section>	</section>

		<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
	<section anchor="iana" title="IANA Considerations">	"section-5">
	<t>	<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	The following two entries are added to the "Application Layer Protocol N	<t indent="0" pn="section-5-1">
	egotiation (ALPN)	The following two entries have been added to the "TLS Application-Layer
	Protocol IDs" registry established by <xref target="RFC7301"/>:	Protocol Negotiation (ALPN) Protocol IDs" registry established by
	<list style="hanging">	<xref target="RFC7301" format="default" sectionFormat="of" derivedContent
	<t hangText="webrtc:">	="RFC7301"/>:
	<vspace blankLines="1"/>	</t>
	The <spanx style="verb">webrtc</spanx> label identifies mixed media	<dl newline="true" spacing="normal" indent="3" pn="section-5-2">
	and data	<dt pn="section-5-2.1">webrtc:</dt>
		<dd pn="section-5-2.2">
		<t indent="0" pn="section-5-2.2.1">
		The <tt>webrtc</tt> label identifies mixed media and data
	communications using SRTP and data channels:	communications using SRTP and data channels:

	<list style="hanging">
	<t hangText="Protocol:">WebRTC Media and Data</t>
	<t hangText="Identification Sequence:">0x77 0x65 0x62 0x72 0x74 0x
	63 ("webrtc")</t>
	<t hangText="Specification:">This document (RFCXXXX)</t>
	</list>
	</t>	</t>

	<t hangText="c-webrtc:">	<dl newline="false" spacing="normal" indent="3" pn="section-5-2.2.2">
	<vspace blankLines="1"/>	<dt pn="section-5-2.2.2.1">Protocol:</dt>
	The <spanx style="verb">c-webrtc</spanx> label identifies WebRTC	<dd pn="section-5-2.2.2.2">WebRTC Media and Data</dd>
	communications with a promise to protect media confidentiality:	<dt pn="section-5-2.2.2.3">Identification Sequence:</dt>
	<list style="hanging">	<dd pn="section-5-2.2.2.4">0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")<
	<t hangText="Protocol:">Confidential WebRTC Media and Data</t>	/dd>
	<t hangText="Identification Sequence:">0x63 0x2d 0x77 0x65 0x62 0x	<dt pn="section-5-2.2.2.5">Specification:</dt>
	72 0x74 0x63	<dd pn="section-5-2.2.2.6">RFC 8833 (this document)</dd>
	("c-webrtc")</t>	</dl>
	<t hangText="Specification:">This document (RFCXXXX)</t>	</dd>
	</list>	<dt pn="section-5-2.3">c-webrtc:</dt>
		<dd pn="section-5-2.4">
		<t indent="0" pn="section-5-2.4.1">
		The <tt>c-webrtc</tt> label identifies WebRTC
		with a promise to protect media confidentiality:
	</t>	</t>

	</list>	<dl newline="false" spacing="normal" indent="3" pn="section-5-2.4.2">
	</t>	<dt pn="section-5-2.4.2.1">Protocol:</dt>
		<dd pn="section-5-2.4.2.2">Confidential WebRTC Media and Data</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")</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>	</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>	</middle>


	<back>	<back>

		<references pn="section-6">
	<references title="Normative References">	<name slugifiedName="name-references">References</name>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211	<references pn="section-6.1">
	9.xml"?>	<name slugifiedName="name-normative-references">Normative References</na
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.634	me>
	7.xml"?>	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.576	119" quoteTitle="true" derivedAnchor="RFC2119">
	4.xml"?>	<front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.730	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	1.xml"?>	le>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie	<author initials="S." surname="Bradner" fullname="S. Bradner">
	tf-rtcweb-security-arch.xml"?>	<organization showOnFrontPage="true"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie	</author>
	tf-rtcweb-data-channel.xml"?>	<date year="1997" month="March"/>
	</references>	<abstract>
		<t indent="0">In many standards track documents several words are
	<references title="Informative References">	used to signify the requirements in the specification. These words are often ca
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.496	pitalized. This document defines these words as they should be interpreted in IE
	0.xml"?>	TF documents. This document specifies an Internet Best Current Practices for th
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.524	e Internet Community, and requests discussion and suggestions for improvements.<
	5.xml"?>	/t>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie	</abstract>
	tf-rtcweb-overview.xml"?>	</front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie	<seriesInfo name="BCP" value="14"/>
	tf-rtcweb-transports.xml"?>	<seriesInfo name="RFC" value="2119"/>
	<reference anchor="HTML5" target="http://www.w3.org/TR/2012/CR-html5-20121	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	217/">	</reference>
	<front>	<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5
	<title>	764" quoteTitle="true" derivedAnchor="RFC5764">
	HTML 5	<front>
	</title>	<title>Datagram Transport Layer Security (DTLS) Extension to Establi
	<author initials="R." surname="Berjon" fullname="Robin Berjon"/>	sh Keys for the Secure Real-time Transport Protocol (SRTP)</title>
	<author initials="T." surname="Leithead" fullname="Travis Leithead"/>	<author initials="D." surname="McGrew" fullname="D. McGrew">
	<author initials="E." surname="Doyle Navara" fullname="Erika Doyle Nav	<organization showOnFrontPage="true"/>
	ara"/>	</author>
	<author initials="E." surname="O'Connor" fullname="Edward O'Connor"/>	<author initials="E." surname="Rescorla" fullname="E. Rescorla">
	<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/>	<organization showOnFrontPage="true"/>
	<date year="2010" month="August"/>	</author>
	</front>	<date year="2010" month="May"/>
	<seriesInfo name="CR" value="CR-html5-20121217"/>	<abstract>
	</reference>	<t indent="0">This document describes a Datagram Transport Layer S
		ecurity (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP
		Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independ
		ent 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/rfc6
		347" 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 communicat
		ions privacy for datagram protocols. The protocol allows client/server applicat
		ions to communicate in a way that is designed to prevent eavesdropping, tamperin
		g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
		ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
		cs of the underlying transport are preserved by the DTLS protocol. This documen
		t 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/rfc7
		301" quoteTitle="true" derivedAnchor="RFC7301">
		<front>
		<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
		otiation 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 handsha
		ke. For instances in which multiple application protocols are supported on the s
		ame TCP or UDP port, this extension allows the application layer to negotiate wh
		ich 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/rfc8
		174" quoteTitle="true" derivedAnchor="RFC8174">
		<front>
		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
		tle>
		<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 cla
		rifying that only UPPERCASE usage of the key words have the defined special mea
		nings.</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/rfc8
		827" 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/rfc8
		831" 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/rfc4
		960" 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 d
		escribes the Stream Control Transmission Protocol (SCTP). SCTP is designed to t
		ransport Public Switched Telephone Network (PSTN) signaling messages over IP net
		works, but is capable of broader applications.</t>
		<t indent="0">SCTP is a reliable transport protocol operating on t
		op of a connectionless packet network such as IP. It offers the following servi
		ces 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 multi
		ple streams, with an option for order-of-arrival delivery of individual user mes
		sages,</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. [STANDARD
		S-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/rfc8
		445" 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 Addre
		ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
		led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
		Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
		elay 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/rfc8
		825" quoteTitle="true" derivedAnchor="RFC8825">
		<front>
		<title>Overview: Real-Time Protocols for Browser-Based Applications<
		/title>
		<author initials="H." surname="Alvestrand" fullname="Harald T. Alves
		trand">
		<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/rfc8
		835" quoteTitle="true" derivedAnchor="RFC8835">
		<front>
		<title>Transports for WebRTC</title>
		<author initials="H." surname="Alvestrand" fullname="Harald Alvestra
		nd">
		<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>	</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>	</back>
	</rfc>	</rfc>

End of changes. 53 change blocks.
	248 lines changed or deleted	583 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/