draft-ietf-rtcweb-alpn-04.txt		rfc8833.txt
	RTCWEB M. Thomson		Internet Engineering Task Force (IETF) M. Thomson
	Internet-Draft Mozilla		Request for Comments: 8833 Mozilla
	Intended status: Standards Track May 5, 2016		Category: Standards Track January 2021
	Expires: November 6, 2016		ISSN: 2070-1721
	Application Layer Protocol Negotiation for Web Real-Time Communications		Application-Layer Protocol Negotiation (ALPN) for WebRTC
	(WebRTC)
	draft-ietf-rtcweb-alpn-04
	Abstract		Abstract
	This document specifies two Application Layer Protocol Negotiation		This document specifies two Application-Layer Protocol Negotiation
	(ALPN) labels for use with Web Real-Time Communications (WebRTC).		(ALPN) labels for use with Web Real-Time Communication (WebRTC). The
	The "webrtc" label identifies regular WebRTC communications: a DTLS		"webrtc" label identifies regular WebRTC: a DTLS session that is used
	session that is used establish keys for Secure Real-time Transport		to establish keys for the Secure Real-time Transport Protocol (SRTP)
	Protocol (SRTP) or to establish data channels using SCTP over DTLS.		or to establish data channels using the Stream Control Transmission
	The "c-webrtc" label describes the same protocol, but the peers also		Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same
	agree to maintain the confidentiality of the media by not sharing it		protocol, but the peers also agree to maintain the confidentiality of
	with other applications.		the media by not sharing it with other applications.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on November 6, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8833.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2		1.1. Conventions
	2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2		2. ALPN Labels for WebRTC
	3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3		3. Media Confidentiality
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 4		4. Security Considerations
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. References
	6.1. Normative References . . . . . . . . . . . . . . . . . . 6		6.1. Normative References
	6.2. Informative References . . . . . . . . . . . . . . . . . 6		6.2. Informative References
	6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses		Web Real-Time Communication (WebRTC) [RFC8825] uses Datagram
	Datagram Transport Layer Security (DTLS) [RFC6347] to secure all		Transport Layer Security (DTLS) [RFC6347] to secure all peer-to-peer
	peer-to-peer communications.		communications.
	Identifying WebRTC protocol usage with Application Layer Protocol		Identifying WebRTC protocol usage with Application-Layer Protocol
	Negotiation (ALPN) [RFC7301] enables an endpoint to positively		Negotiation (ALPN) [RFC7301] enables an endpoint to positively
	identify WebRTC uses and distinguish them from other DTLS uses.		identify WebRTC uses and distinguish them from other DTLS uses.
	Different WebRTC uses can be advertised and behavior can be		Different WebRTC uses can be advertised and behavior can be
	constrained to what is appropriate to a given use. In particular,		constrained to what is appropriate to a given use. In particular,
	this allows for the identification of sessions that require		this allows for the identification of sessions that require
	confidentiality protection from the application that manages the		confidentiality protection from the application that manages the
	signaling for the session.		signaling for the session.
	1.1. Conventions and Terminology		1.1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in BCP
	[RFC2119].		14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. ALPN Labels for WebRTC		2. ALPN Labels for WebRTC
	The following identifiers are defined for use in ALPN:		The following identifiers are defined for use in ALPN:
	webrtc: The DTLS session is used to establish keys for Secure Real-		webrtc: The DTLS session is used to establish keys for the Secure
	time Transport Protocol (SRTP) - known as DTLS-SRTP - as described		Real-time Transport Protocol (SRTP) -- known as DTLS-SRTP -- as
	in [RFC5764]. The DTLS record layer is used for WebRTC data		described in [RFC5764]. The DTLS record layer is used for WebRTC
	channels [I-D.ietf-rtcweb-data-channel].		data channels [RFC8831].
	c-webrtc: The DTLS session is used for confidential WebRTC		c-webrtc: The DTLS session is used for confidential WebRTC, where
	communications, where peers agree to maintain the confidentiality		peers agree to maintain the confidentiality of the media, as
	of the media, as described in Section 3. The confidentiality		described in Section 3. The confidentiality protections ensure
	protections ensure that media is protected from other		that media is protected from other applications, but the
	applications, but the confidentiality protections do not extend to		confidentiality protections do not extend to messages on data
	messages on data channels.		channels.
	Both identifiers describe the same basic protocol: a DTLS session		Both identifiers describe the same basic protocol: a DTLS session
	that is used to provide keys for an SRTP session in combination with		that is used to provide keys for an SRTP session in combination with
	WebRTC data channels. Either SRTP or data channels could be absent.		WebRTC data channels. Either SRTP or data channels could be absent.
	The data channels send Stream Control Transmission Protocol (SCTP)		The data channels send the Stream Control Transmission Protocol
	[RFC4960] over the DTLS record layer, which can be multiplexed with		(SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed
	SRTP on the same UDP flow. WebRTC requires the use of Interactive		with SRTP on the same UDP flow. WebRTC requires the use of
	Communication Establishment (ICE) [RFC5245] to establish the UDP		Interactive Connectivity Establishment (ICE) [RFC8445] to establish
	flow, but this is not covered by the identifier.		UDP flow, but this is not covered by the identifier.
	A more thorough definition of what WebRTC communications entail is		A more thorough definition of what WebRTC entails is included in
	included in [I-D.ietf-rtcweb-transports].		[RFC8835].
	There is no functional difference between the identifiers except that		There is no functional difference between the identifiers except that
	an endpoint negotiating "c-webrtc" makes a promise to preserve the		an endpoint negotiating "c-webrtc" makes a promise to preserve the
	confidentiality of the media it receives.		confidentiality of the media it receives.
	A peer that is not aware of whether it needs to request		A peer that is not aware of whether it needs to request
	confidentiality can use either identifier. A peer in the client role		confidentiality can use either identifier. A peer in the client role
	MUST offer both identifiers if it is not aware of a need for		MUST offer both identifiers if it is not aware of a need for
	confidentiality. A peer in the server role SHOULD select "webrtc" if		confidentiality. A peer in the server role SHOULD select "webrtc" if
	it does not prefer either.		it does not prefer either.
	An endpoint that requires media confidentiality might negotiate a		An endpoint that requires media confidentiality might negotiate a
	session with a peer that does not support this specification.		session with a peer that does not support this specification. An
	Endpoint MUST abort a session if it requires confidentiality but does		endpoint MUST abort a session if it requires confidentiality but does
	not successfully negotiate "c-webrtc". A peer that is willing to		not successfully negotiate "c-webrtc". A peer that is willing to
	accept "webrtc" SHOULD assume that a peer that does not support this		accept "webrtc" SHOULD assume that a peer that does not support this
	specification has negotiated "webrtc" unless signaling provides other		specification has negotiated "webrtc" unless signaling provides other
	information; however, a peer MUST NOT assume that "c-webrtc" has been		information; however, a peer MUST NOT assume that "c-webrtc" has been
	negotiated unless explicitly negotiated.		negotiated unless explicitly negotiated.
	3. Media Confidentiality		3. Media Confidentiality
	Private communications in WebRTC depend on separating control (i.e.,		Private communications in WebRTC depend on separating control (i.e.,
	signaling) capabilities and access to media		signaling) capabilities and access to media [RFC8827]. In this way,
	[I-D.ietf-rtcweb-security-arch]. In this way, an application can		an application can establish a session that is end-to-end
	establish a session that is end-to-end confidential, where the ends		confidential, where the ends in question are user agents (or
	in question are user agents (or browsers) and not the signaling		browsers) and not the signaling application. This allows an
	application. This allows an application to manage signaling for a		application to manage signaling for a session without having access
	session, without having access to the media that is exchanged in the		to the media that is exchanged in the session.
	session.
	Without some form of indication that is securely bound to the		Without some form of indication that is securely bound to the
	session, a WebRTC endpoint is unable to properly distinguish between		session, a WebRTC endpoint is unable to properly distinguish between
	a session that requires this confidentiality protection and one that		a session that requires this confidentiality protection and one that
	does not. The ALPN identifier provides that signal.		does not. The ALPN identifier provides that signal.
	A browser is required to enforce this confidentiality protection		A browser is required to enforce this confidentiality protection
	using isolation controls similar to those used in content cross-		using isolation controls similar to those used in content cross-
	origin protections (see Section 5.3 [1] of [HTML5]). These		origin protections (see the "Origin" section of [HTML5]). These
	protections ensure that media is protected from applications.		protections ensure that media is protected from applications, which
	Applications are not able to read or modify the contents of a		are not able to read or modify the contents of a protected flow of
	protected flow of media. Media that is produced from a session using		media. Media that is produced from a session using the "c-webrtc"
	the "c-webrtc" identifier MUST only be displayed to users.		identifier MUST only be displayed to users.
	The promise to apply confidentiality protections do not apply to data		The promise to apply confidentiality protections do not apply to data
	that is sent using data channels. Confidential data depends on		that is sent using data channels. Confidential data depends on
	having both data sources and consumers that are exclusively browser-		having both data sources and consumers that are exclusively browser
	or user-based. No mechanisms currently exist to take advantage of		or user based. No mechanisms currently exist to take advantage of
	data confidentiality, though some use cases suggest that this could		data confidentiality, though some use cases suggest that this could
	be useful, for example, confidential peer-to-peer file transfer.		be useful, for example, confidential peer-to-peer file transfer.
	Alternative labels might be provided in future to support these use		Alternative labels might be provided in the future to support these
	cases.		use cases.
	This mechanism explicitly does not define a specific authentication		This mechanism explicitly does not define a specific authentication
	method; a WebRTC endpoint that accepts a session with this ALPN		method; a WebRTC endpoint that accepts a session with this ALPN
	identifier MUST respect confidentiality no matter what identity is		identifier MUST respect confidentiality no matter what identity is
	attributed to a peer.		attributed to a peer.
	RTP middleboxes and entities that forward media or data cannot		RTP middleboxes and entities that forward media or data cannot
	promise to maintain confidentiality. Any entity that forwards		promise to maintain confidentiality. Any entity that forwards
	content, or records content for later access by entities other than		content, or records content for later access by entities other than
	the authenticated peer, MUST NOT offer or accept a session with the		the authenticated peer, MUST NOT offer or accept a session with the
	"c-webrtc" identifier.		"c-webrtc" identifier.
	4. Security Considerations		4. Security Considerations
	Confidential communications depends on more than just an agreement		Confidential communications depend on more than just an agreement
	from browsers.		from browsers.
	Information is not confidential if it is displayed to those other		Information is not confidential if it is displayed to others than for
	than to whom it is intended. Peer authentication		whom it is intended. Peer authentication [RFC8827] is necessary to
	[I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is		ensure that data is only sent to the intended peer.
	only sent to the intended peer.
	This is not a digital rights management mechanism. A user is not		This is not a digital rights management mechanism. A user is not
	prevented from using other mechanisms to record or forward media.		prevented from using other mechanisms to record or forward media.
	This means that (for example) screen recording devices, tape		This means that (for example) screen-recording devices, tape
	recorders, portable cameras, or a cunning arrangement of mirrors		recorders, portable cameras, or a cunning arrangement of mirrors
	could variously be used to record or redistribute media once		could variously be used to record or redistribute media once
	delivered. Similarly, if media is visible or audible (or otherwise		delivered. Similarly, if media is visible or audible (or otherwise
	accessible) to others in the vicinity, there are no technical		accessible) to others in the vicinity, there are no technical
	measures that protect the confidentiality of that media.		measures that protect the confidentiality of that media.
	The only guarantee provided by this mechanism and the browser that		The only guarantee provided by this mechanism and the browser that
	implements it is that the media was delivered to the user that was		implements it is that the media was delivered to the user that was
	authenticated. Individual users will still need to make a judgment		authenticated. Individual users will still need to make a judgment
	about how their peer intends to respect the confidentiality of any		about how their peer intends to respect the confidentiality of any
	information provided.		information provided.
	On a shared computing platform like a browser, other entities with		On a shared computing platform like a browser, other entities with
	access to that platform (i.e., web applications), might be able to		access to that platform (i.e., web applications) might be able to
	access information that would compromise the confidentiality of		access information that would compromise the confidentiality of
	communications. Implementations MAY choose to limit concurrent		communications. Implementations MAY choose to limit concurrent
	access to input devices during confidential communications sessions.		access to input devices during confidential communications sessions.
	For instance, another application that is able to access a microphone		For instance, another application that is able to access a microphone
	might be able to sample confidential audio that is playing through		might be able to sample confidential audio that is playing through
	speakers. This is true even if acoustic echo cancellation, which		speakers. This is true even if acoustic echo cancellation, which
	attempts to prevent this from happening, is used. Similarly, an		attempts to prevent this from happening, is used. Similarly, an
	application with access to a video camera might be able to use		application with access to a video camera might be able to use
	reflections to obtain all or part of a confidential video stream.		reflections to obtain all or part of a confidential video stream.
	5. IANA Considerations		5. IANA Considerations
	The following two entries are added to the "Application Layer		The following two entries have been added to the "TLS Application-
	Protocol Negotiation (ALPN) Protocol IDs" registry established by		Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
	[RFC7301]:		by [RFC7301]:
	webrtc:		webrtc:
	The "webrtc" label identifies mixed media and data communications		The "webrtc" label identifies mixed media and data communications
	using SRTP and data channels:		using SRTP and data channels:
	Protocol: WebRTC Media and Data		Protocol: WebRTC Media and Data
	Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")		Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")
	Specification: This document (RFCXXXX)		Specification: RFC 8833 (this document)
	c-webrtc:		c-webrtc:
			The "c-webrtc" label identifies WebRTC with a promise to protect
	The "c-webrtc" label identifies WebRTC communications with a		media confidentiality:
	promise to protect media confidentiality:
	Protocol: Confidential WebRTC Media and Data		Protocol: Confidential WebRTC Media and Data
	Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63		Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63
	("c-webrtc")		("c-webrtc")
	Specification: This document (RFCXXXX)		Specification: RFC 8833 (this document)
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-rtcweb-data-channel]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
	Channels", draft-ietf-rtcweb-data-channel-13 (work in
	progress), January 2015.
	[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-11 (work in progress), March 2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,		Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<http://www.rfc-editor.org/info/rfc5764>.		<https://www.rfc-editor.org/info/rfc5764>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <http://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	6.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E.,		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
	and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August		DOI 10.17487/RFC8827, January 2021,
	2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>.		<https://www.rfc-editor.org/info/rfc8827>.
	[I-D.ietf-rtcweb-overview]		[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
	Alvestrand, H., "Overview: Real Time Protocols for		Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
	Browser-based Applications", draft-ietf-rtcweb-overview-15		<https://www.rfc-editor.org/info/rfc8831>.
	(work in progress), January 2016.
	[I-D.ietf-rtcweb-transports]		6.2. Informative References
	Alvestrand, H., "Transports for WebRTC", draft-ietf-
	rtcweb-transports-12 (work in progress), March 2016.		[HTML5] WHATWG, "HTML - Living Standard", Section 7.5, January
			2021, <https://html.spec.whatwg.org/#origin>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<http://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	(ICE): A Protocol for Network Address Translator (NAT)		Connectivity Establishment (ICE): A Protocol for Network
	Traversal for Offer/Answer Protocols", RFC 5245,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC5245, April 2010,		DOI 10.17487/RFC8445, July 2018,
	<http://www.rfc-editor.org/info/rfc5245>.		<https://www.rfc-editor.org/info/rfc8445>.
	6.3. URIs		[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
			Browser-Based Applications", RFC 8825,
			DOI 10.17487/RFC8825, January 2021,
			<https://www.rfc-editor.org/info/rfc8825>.
	[1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin		[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835,
			DOI 10.17487/RFC8835, January 2021,
			<https://www.rfc-editor.org/info/rfc8835>.
	Author's Address		Author's Address
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	331 E Evelyn Street
	Mountain View, CA 94041
	US
	Email: martin.thomson@gmail.com		Email: martin.thomson@gmail.com
End of changes. 45 change blocks.
	133 lines changed or deleted		119 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/