draft-ietf-rtcweb-alpn-00.txt		draft-ietf-rtcweb-alpn-01.txt
	RTCWEB M. Thomson		RTCWEB M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track July 23, 2014		Intended status: Standards Track February 28, 2015
	Expires: January 24, 2015		Expires: September 1, 2015
	Application Layer Protocol Negotiation for Web Real-Time Communications		Application Layer Protocol Negotiation for Web Real-Time Communications
	(WebRTC)		(WebRTC)
	draft-ietf-rtcweb-alpn-00		draft-ietf-rtcweb-alpn-01
	Abstract		Abstract
	Application Layer Protocol Negotiation (ALPN) labels are defined for		Application Layer Protocol Negotiation (ALPN) labels are defined for
	use in identifying Web Real-Time Communications (WebRTC) usages of		use in identifying Web Real-Time Communications (WebRTC) usages of
	Datagram Transport Layer Security (DTLS). Labels are provided for		Datagram Transport Layer Security (DTLS). Labels are provided for
	identifying a session that uses a combination of WebRTC compatible		identifying a session that uses a combination of WebRTC compatible
	media and data, and for identifying a session requiring		media and data, and for identifying a session requiring
	confidentiality protection.		confidentiality protection.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 24, 2015.		This Internet-Draft will expire on September 1, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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		(http://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
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	webrtc: The DTLS session is used to establish keys for a Secure		webrtc: The DTLS session is used to establish keys for a Secure
	Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as		Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as
	described in [RFC5764]. The DTLS record layer is used for WebRTC		described in [RFC5764]. The DTLS record layer is used for WebRTC
	data channels [I-D.ietf-rtcweb-data-channel].		data channels [I-D.ietf-rtcweb-data-channel].
	c-webrtc: The DTLS session is used for confidential WebRTC		c-webrtc: The DTLS session is used for confidential WebRTC
	communications, where peers agree to maintain the confidentiality		communications, where peers agree to maintain the confidentiality
	of the communications, as described in Section 3.		of the communications, as described in Section 3.
	A more thorough definition of what WebRTC communications entail is
	included in [I-D.ietf-rtcweb-transports].
	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 MAY be absent.		WebRTC data channels. Either SRTP or data channels MAY be absent.
	The data channels send Stream Control Transmission Protocol (SCTP)		The data channels send Stream Control Transmission Protocol (SCTP)
	[RFC4960] over the DTLS record layer, which can be multiplexed with		[RFC4960] over the DTLS record layer, which can be multiplexed with
	SRTP on the same UDP flow. WebRTC requires the use of Interactive		SRTP on the same UDP flow. WebRTC requires the use of Interactive
	Communication Establishment (ICE) [RFC5245] to establish the UDP		Communication Establishment (ICE) [RFC5245] to establish the UDP
	flow, but this is not covered by the identifier.		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 communications entail is
	included in [I-D.ietf-rtcweb-transports].		included in [I-D.ietf-rtcweb-transports].
	There is no functional difference between the identifiers except with		There is no functional difference between the identifiers except that
	respect to the promise that an endpoint makes with respect to the		an endpoint negotiating "c-webrtc" makes a promise to preserve the
	confidentiality of session content. An endpoint negotiating		confidentiality of the data it receives.
	"c-webrtc" makes a promise to preserve the confidentiality of the
	data it receives.
	Only one of these labels can be used for any given session. A peer		A peer that is not aware of whether it needs to request
	acting in the client role MUST NOT offer both identifiers. A peer in		confidentiality can use either form. A peer in the client role MUST
	the server role that receives a ClientHello containing both labels		offer both identifiers if it is not aware of a need for
	MUST reject the session, though it MAY accept the confidential option		confidentiality. A peer in the server role SHOULD select "webrtc" if
	and protect content accordingly.		it does not prefer either.
	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
	[I-D.ietf-rtcweb-security-arch]. In this way, an application can		[I-D.ietf-rtcweb-security-arch]. In this way, an application can
	establish a session that is end-to-end confidential, where the ends		establish a session that is end-to-end confidential, where the ends
	in question are user agents (or browsers) and not the signaling		in question are user agents (or browsers) and not the signaling
	application.		application.
	skipping to change at page 4, line 18		skipping to change at page 4, line 13
	not.		not.
	A browser is required to enforce confidentiality using isolation		A browser is required to enforce confidentiality using isolation
	controls similar to those used in content cross-origin protections		controls similar to those used in content cross-origin protections
	(see Section 5.3 [1] of [HTML5]). These protections ensure that		(see Section 5.3 [1] of [HTML5]). These protections ensure that
	media is protected from applications. Applications are not able to		media is protected from applications. Applications are not able to
	read or modify the contents of a protected flow of media. Media that		read or modify the contents of a protected flow of media. Media that
	is produced from a session using the "c-webrtc" identifier MUST only		is produced from a session using the "c-webrtc" identifier MUST only
	be displayed to users.		be displayed to users.
	Confidentiality protections of this sort are not expected to be		These confidentiality protections do not apply to data that is sent
	possible for data that is sent using data channels. Thus, it is		using data channels. Confidential data depends on having both data
	expected that data channels will not be employed for sessions that		sources and consumers that are exclusively browser- or user-based.
	negotiate confidentiality. In the browser context, confidential data		No mechanisms currently exist to take advantage of data
	depends on having both data sources and consumers that are		confidentiality, though some use cases suggest that this could be
	exclusively browser- or user-based. No mechanisms currently exist to		useful, for example, confidential peer-to-peer file transfer.
	take advantage of data confidentiality, though some use cases suggest		Alternative labels might be provided in future to support these use
	that this could be useful, for example, confidential peer-to-peer		cases.
	file transfer.
	Generally speaking, ensuring confidentiality depends on		Generally speaking, ensuring confidentiality depends on
	authenticating the communications peer. This mechanism explicitly		authenticating the communications peer. This mechanism explicitly
	does not define a specific authentication method; a WebRTC endpoint		does not define a specific authentication method; a WebRTC endpoint
	that accepts a session with this ALPN identifier MUST respect		that accepts a session with this ALPN identifier MUST respect
	confidentiality no matter what identity is attributed to a peer.		confidentiality no matter what identity is 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, SHOULD 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 depends 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 those other
	than to whom it is intended. Peer authentication		than to whom it is intended. Peer authentication
	[I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is		[I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is
	skipping to change at page 6, line 15		skipping to change at page 6, line 11
	("c-webrtc")		("c-webrtc")
	Specification: This document (RFCXXXX)		Specification: This document (RFCXXXX)
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-rtcweb-data-channel]		[I-D.ietf-rtcweb-data-channel]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
	Channels", draft-ietf-rtcweb-data-channel-09 (work in		Channels", draft-ietf-rtcweb-data-channel-11 (work in
	progress), May 2014.		progress), July 2014.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	skipping to change at page 6, line 39		skipping to change at page 6, line 35
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, July 2014.		Negotiation Extension", RFC 7301, July 2014.
	6.2. Informative References		6.2. Informative References
	[HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E.,		[HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E.,
	and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August		and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August
	2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>.		2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for Brower-		Alvestrand, H., "Overview: Real Time Protocols for
	based Applications", draft-ietf-rtcweb-overview-09 (work		Browser-based Applications", draft-ietf-rtcweb-overview-11
	in progress), February 2014.		(work in progress), August 2014.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-09 (work in progress), February 2014.		rtcweb-security-arch-10 (work in progress), July 2014.
	[I-D.ietf-rtcweb-transports]		[I-D.ietf-rtcweb-transports]
	Alvestrand, H., "Transports for RTCWEB", draft-ietf-		Alvestrand, H., "Transports for WebRTC", draft-ietf-
	rtcweb-transports-04 (work in progress), April 2014.		rtcweb-transports-06 (work in progress), August 2014.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC		[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
	4960, September 2007.		4960, September 2007.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245, April
	2010.		2010.
	6.3. URIs		6.3. URIs
End of changes. 13 change blocks.
	36 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/