rfc8826v4.txt		rfc8826.txt
	Internet Engineering Task Force (IETF) E. Rescorla		Internet Engineering Task Force (IETF) E. Rescorla
	Request for Comments: 8826 RTFM, Inc.		Request for Comments: 8826 Mozilla
	Category: Standards Track December 2020		Category: Standards Track January 2021
	ISSN: 2070-1721		ISSN: 2070-1721
	Security Considerations for WebRTC		Security Considerations for WebRTC
	Abstract		Abstract
	WebRTC is a protocol suite for use with real-time applications that		WebRTC is a protocol suite for use with real-time applications that
	can be deployed in browsers -- "real-time communication on the Web".		can be deployed in browsers -- "real-time communication on the Web".
	This document defines the WebRTC threat model and analyzes the		This document defines the WebRTC threat model and analyzes the
	security threats of WebRTC in that model.		security threats of WebRTC in that model.
	skipping to change at line 32 ¶		skipping to change at line 32 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8826.		https://www.rfc-editor.org/info/rfc8826.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	(https://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
	skipping to change at line 115 ¶		skipping to change at line 115 ¶
	communications are directly controlled by some Web server. A simple		communications are directly controlled by some Web server. A simple
	case is shown below.		case is shown below.
	+----------------+		+----------------+
	| |		| |
	| Web Server |		| Web Server |
	| |		| |
	+----------------+		+----------------+
	^ ^		^ ^
	/ \		/ \
	HTTP / \ HTTP		HTTPS / \ HTTPS
	or / \ or		or / \ or
	WebSockets / \ WebSockets		WebSockets / \ WebSockets
	v v		v v
	JS API JS API		JS API JS API
	+-----------+ +-----------+		+-----------+ +-----------+
	| | Media | |		| | Media | |
	| Browser |<---------->| Browser |		| Browser |<---------->| Browser |
	| | | |		| | | |
	+-----------+ +-----------+		+-----------+ +-----------+
	Alice Bob		Alice Bob
	skipping to change at line 279 ¶		skipping to change at line 279 ¶
	response transactions. As with CORS, a WebSockets transaction starts		response transactions. As with CORS, a WebSockets transaction starts
	with a consent verification stage to avoid allowing scripts to simply		with a consent verification stage to avoid allowing scripts to simply
	send arbitrary data to another origin.		send arbitrary data to another origin.
	While consent verification is conceptually simple -- just do a		While consent verification is conceptually simple -- just do a
	handshake before you start exchanging the real data -- experience has		handshake before you start exchanging the real data -- experience has
	shown that designing a correct consent verification system is		shown that designing a correct consent verification system is
	difficult. In particular, Huang et al. [huang-w2sp] have shown		difficult. In particular, Huang et al. [huang-w2sp] have shown
	vulnerabilities in the existing Java and Flash consent verification		vulnerabilities in the existing Java and Flash consent verification
	techniques and in a simplified version of the WebSockets handshake.		techniques and in a simplified version of the WebSockets handshake.
	In particular, it is important to be wary of CROSS-PROTOCOL attacks		It is important to be wary of CROSS-PROTOCOL attacks in which the
	in which the attacking script generates traffic which is acceptable		attacking script generates traffic which is acceptable to some non-
	to some non-Web protocol state machine. In order to resist this form		Web protocol state machine. In order to resist this form of attack,
	of attack, WebSockets incorporates a masking technique intended to		WebSockets incorporates a masking technique intended to randomize the
	randomize the bits on the wire, thus making it more difficult to		bits on the wire, thus making it more difficult to generate traffic
	generate traffic which resembles a given protocol.		which resembles a given protocol.
	4. Security for WebRTC Applications		4. Security for WebRTC Applications
	4.1. Access to Local Devices		4.1. Access to Local Devices
	As discussed in Section 1, allowing arbitrary sites to initiate calls		As discussed in Section 1, allowing arbitrary sites to initiate calls
	violates the core Web security guarantee; without some access		violates the core Web security guarantee; without some access
	restrictions on local devices, any malicious site could simply bug a		restrictions on local devices, any malicious site could simply bug a
	user. At minimum, then, it MUST NOT be possible for arbitrary sites		user. At minimum, then, it MUST NOT be possible for arbitrary sites
	to initiate calls to arbitrary locations without user consent. This		to initiate calls to arbitrary locations without user consent. This
	skipping to change at line 587 ¶		skipping to change at line 587 ¶
	There also needs to be some mechanism for the browser to verify that		There also needs to be some mechanism for the browser to verify that
	the target of the traffic continues to wish to receive it. Because		the target of the traffic continues to wish to receive it. Because
	ICE keepalives are indications, they will not work here. [RFC7675]		ICE keepalives are indications, they will not work here. [RFC7675]
	describes the mechanism for providing consent freshness.		describes the mechanism for providing consent freshness.
	4.2.2. Masking		4.2.2. Masking
	Once consent is verified, there still is some concern about		Once consent is verified, there still is some concern about
	misinterpretation attacks as described by Huang et al. [huang-w2sp].		misinterpretation attacks as described by Huang et al. [huang-w2sp].
	Where TCP is used, the risk is substantial due to the potential		This does not seem like it is of serious concern with DTLS because
	presence of transparent proxies; therefore, if TCP is to be used,		the ICE handshake enforces receiver consent and there is little
	then WebSockets-style masking MUST be employed.		evidence of passive DTLS proxies of the type studied by Huang.
			However, because RTCWEB can run over TCP there is some concern that
	Since DTLS (with the anti-chosen plaintext mechanisms required by TLS		attackers might control the ciphertext by controlling the plaintext
	1.1) does not allow the attacker to generate predictable ciphertext,		input to SCTP. This risk is only partially mitigated by the fact
	there is no need for masking of protocols running over DTLS (e.g.,		that the SCTP stack controls the framing of the packets.
	SCTP over DTLS, UDP over DTLS, etc.).
	Note that in principle an attacker could exert some control over		Note that in principle an attacker could exert some control over
	Secure Real-time Transport Protocol (SRTP) packets by using a		Secure Real-time Transport Protocol (SRTP) packets by using a
	combination of the WebAudio API and extremely tight timing control.		combination of the WebAudio API and extremely tight timing control.
	The primary risk here seems to be carriage of SRTP over Traversal		The primary risk here seems to be carriage of SRTP over Traversal
	Using Relays around NAT (TURN) TCP. However, as SRTP packets have an		Using Relays around NAT (TURN) TCP. However, as SRTP packets have an
	extremely characteristic packet header it seems unlikely that any but		extremely characteristic packet header it seems unlikely that any but
	the most aggressive intermediaries would be confused into thinking		the most aggressive intermediaries would be confused into thinking
	that another application-layer protocol was in use.		that another application-layer protocol was in use.
	4.2.3. Backward Compatibility		4.2.3. Backward Compatibility
			| Note: The RTCWEB WG ultimately decided to require ICE. This
			| section provides context for that decision.
	A requirement to use ICE limits compatibility with legacy non-ICE		A requirement to use ICE limits compatibility with legacy non-ICE
	clients. It seems unsafe to completely remove the requirement for		clients. It seems unsafe to completely remove the requirement for
	some check. All proposed checks have the common feature that the		some check. All proposed checks have the common feature that the
	browser sends some message to the candidate traffic recipient and		browser sends some message to the candidate traffic recipient and
	refuses to send other traffic until that message has been replied to.		refuses to send other traffic until that message has been replied to.
	The message/reply pair must be generated in such a way that an		The message/reply pair must be generated in such a way that an
	attacker who controls the Web application cannot forge them,		attacker who controls the Web application cannot forge them,
	generally by having the message contain some secret value that must		generally by having the message contain some secret value that must
	be incorporated (e.g., echoed, hashed into, etc.). Non-ICE		be incorporated (e.g., echoed, hashed into, etc.). Non-ICE
	candidates for this role (in cases where the legacy endpoint has a		candidates for this role (in cases where the legacy endpoint has a
	skipping to change at line 731 ¶		skipping to change at line 733 ¶
	The calling service is compromised during the call it wishes to		The calling service is compromised during the call it wishes to
	attack (often called an "active attack").		attack (often called an "active attack").
	Providing security against the former type of attack is practical		Providing security against the former type of attack is practical
	using the techniques discussed in Section 4.3.1. However, it is		using the techniques discussed in Section 4.3.1. However, it is
	extremely difficult to prevent a trusted but malicious calling		extremely difficult to prevent a trusted but malicious calling
	service from actively attacking a user's calls, either by mounting a		service from actively attacking a user's calls, either by mounting a
	Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note		Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note
	that this attack applies equally to a network attacker if		that this attack applies equally to a network attacker if
	communications to the calling service are not secured.) We discuss		communications to the calling service are not secured.) We discuss
	some potential approaches and why they are likely to be impractical		some potential approaches in Section 4.3.2.
	in Section 4.3.2.
	4.3.1. Protecting Against Retrospective Compromise		4.3.1. Protecting Against Retrospective Compromise
	In a retrospective attack, the calling service was uncompromised		In a retrospective attack, the calling service was uncompromised
	during the call, but an attacker subsequently wants to recover the		during the call, but an attacker subsequently wants to recover the
	content of the call. We assume that the attacker has access to the		content of the call. We assume that the attacker has access to the
	protected media stream as well as full control of the calling		protected media stream as well as full control of the calling
	service.		service.
	If the calling service has access to the traffic keying material (as		If the calling service has access to the traffic keying material (as
	skipping to change at line 824 ¶		skipping to change at line 825 ¶
	ZRTP [RFC6189] uses a "Short Authentication String" (SAS) which is		ZRTP [RFC6189] uses a "Short Authentication String" (SAS) which is
	derived from the key agreement protocol. This SAS is designed to be		derived from the key agreement protocol. This SAS is designed to be
	compared by the users (e.g., read aloud over the voice channel or		compared by the users (e.g., read aloud over the voice channel or
	transmitted via an out-of-band channel) and if confirmed by both		transmitted via an out-of-band channel) and if confirmed by both
	sides precludes MITM attack. The intention is that the SAS is used		sides precludes MITM attack. The intention is that the SAS is used
	once and then key continuity (though with a different mechanism from		once and then key continuity (though with a different mechanism from
	that discussed above) is used thereafter.		that discussed above) is used thereafter.
	Unfortunately, the SAS does not offer a practical solution to the		Unfortunately, the SAS does not offer a practical solution to the
	problem of a compromised calling service. "Voice conversion"		problem of a compromised calling service. "Voice cloning" systems,
	systems, which modify voice from one speaker to make it sound like		which mimic the voice of a given speaker are an active area of
	another, are an active area of research. These systems are already		research [deepfakes-ftc] and are already being used in real-world
	good enough to fool both automatic recognition systems		attacks [deepfakes-fraud]. These attacks are likely to improve in
	[farrus-conversion] and humans [kain-conversion] in many cases, and		future, especially in an environment where the user just wants to get
	are of course likely to improve in future, especially in an		on with the phone call. Thus, even if the SAS is effective today, it
	environment where the user just wants to get on with the phone call.		is likely not to be so for much longer.
	Thus, even if the SAS is effective today, it is likely not to be so
	for much longer.
	Additionally, it is unclear that users will actually use an SAS. As		Additionally, it is unclear that users will actually use an SAS. As
	discussed above, the browser UI constraints preclude requiring the		discussed above, the browser UI constraints preclude requiring the
	SAS exchange prior to completing the call and so it must be		SAS exchange prior to completing the call and so it must be
	voluntary; at most the browser will provide some UI indicator that		voluntary; at most the browser will provide some UI indicator that
	the SAS has not yet been checked. However, it is well known that		the SAS has not yet been checked. However, it is well known that
	when faced with optional security mechanisms, many users simply		when faced with optional security mechanisms, many users simply
	ignore them [whitten-johnny].		ignore them [whitten-johnny].
	Once users have checked the SAS once, key continuity is required to		Once users have checked the SAS once, key continuity is required to
	skipping to change at line 992 ¶		skipping to change at line 991 ¶
	prompt.pdf?attredirects=0>.		prompt.pdf?attredirects=0>.
	[cranor-wolf]		[cranor-wolf]
	Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and		Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and
	L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning		L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning
	Effectiveness", Proceedings of the 18th USENIX Security		Effectiveness", Proceedings of the 18th USENIX Security
	Symposium, August 2009,		Symposium, August 2009,
	<https://www.usenix.org/legacy/event/sec09/tech/		<https://www.usenix.org/legacy/event/sec09/tech/
	full_papers/sunshine.pdf>.		full_papers/sunshine.pdf>.
	[farrus-conversion]		[deepfakes-fraud]
	Farrus, M., Erro, D., and J. Hernando, "Speaker		Statt, N., "Thieves are now using AI deepfakes to trick
	Recognition Robustness to Voice Conversion", January 2008.		companies into sending them money", September 2019,
			<https://www.theverge.com/2019/9/5/20851248/deepfakes-ai-
			fake-audio-phone-calls-thieves-trick-companies-stealing-
			money>.
			[deepfakes-ftc]
			Lyons, K., "FTC says the tech behind audio deepfakes is
			getting better", January 2020,
			<https://www.theverge.com/2020/1/29/21080553/ftc-
			deepfakes-audio-cloning-joe-rogan-phone-scams>.
	[fetch] van Kesteren, A., "Fetch",		[fetch] van Kesteren, A., "Fetch",
	<https://fetch.spec.whatwg.org/>.		<https://fetch.spec.whatwg.org/>.
	[finer-grained]		[finer-grained]
	Jackson, C. and A. Barth, "Beware of Finer-Grained		Jackson, C. and A. Barth, "Beware of Finer-Grained
	Origins", Web 2.0 Security and Privacy (W2SP 2008), July		Origins", Web 2.0 Security and Privacy (W2SP 2008), July
	2008.		2008.
	[Fingerprinting]		[Fingerprinting]
	Doty, N., Ed., "Mitigating Browser Fingerprinting in Web		Doty, N., Ed., "Mitigating Browser Fingerprinting in Web
	Specifications", March 2019,		Specifications", March 2019,
	<https://www.w3.org/TR/fingerprinting-guidance/>.		<https://www.w3.org/TR/fingerprinting-guidance/>.
	[huang-w2sp]		[huang-w2sp]
	Huang, L-S., Chen, E.Y., Barth, A., Rescorla, E., and C.		Huang, L-S., Chen, E.Y., Barth, A., Rescorla, E., and C.
	Jackson, "Talking to Yourself for Fun and Profit", Web 2.0		Jackson, "Talking to Yourself for Fun and Profit", Web 2.0
	Security and Privacy (W2SP 2011), May 2011.		Security and Privacy (W2SP 2011), May 2011.
	[kain-conversion]
	Kain, A. and M. Macon, "Design and Evaluation of a Voice
	Conversion Algorithm based on Spectral Envelope Mapping
	and Residual Prediction", Proceedings of the 2001 IEEE
	International Conference on Acoustics, Speech, and Signal
	Processing (ICASSP), DOI 10.1109/ICASSP.2001.941039, May
	2001, <https://ieeexplore.ieee.org/document/941039>.
	[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and		[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0", November 2014,		C. Mortimore, "OpenID Connect Core 1.0", November 2014,
	<https://openid.net/specs/openid-connect-core-1_0.html>.		<https://openid.net/specs/openid-connect-core-1_0.html>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	skipping to change at line 1119 ¶		skipping to change at line 1119 ¶
	October 2015, <https://www.rfc-editor.org/info/rfc7675>.		October 2015, <https://www.rfc-editor.org/info/rfc7675>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,		DOI 10.17487/RFC8445, July 2018,
	<https://www.rfc-editor.org/info/rfc8445>.		<https://www.rfc-editor.org/info/rfc8445>.
	[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for		[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
	Browser-Based Applications", RFC 8825,		Browser-Based Applications", RFC 8825,
	DOI 10.17487/RFC8825, December 2020,		DOI 10.17487/RFC8825, January 2021,
	<https://www.rfc-editor.org/info/rfc8825>.		<https://www.rfc-editor.org/info/rfc8825>.
	[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
	DOI 10.17487/RFC8827, December 2020,		DOI 10.17487/RFC8827, January 2021,
	<https://www.rfc-editor.org/info/rfc8827>.		<https://www.rfc-editor.org/info/rfc8827>.
	[RFC8828] Uberti, J., "WebRTC IP Address Handling Requirements",		[RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling
	RFC 8828, DOI 10.17487/RFC8828, December 2020,		Requirements", RFC 8828, DOI 10.17487/RFC8828, January
	<https://www.rfc-editor.org/info/rfc8828>.		2021, <https://www.rfc-editor.org/info/rfc8828>.
	[SWF] "SWF File Format Specification Version 19", April 2013,		[SWF] "SWF File Format Specification Version 19", April 2013,
	<https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-		<https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-
	file-format-spec.pdf>.		file-format-spec.pdf>.
	[whitten-johnny]		[whitten-johnny]
	Whitten, A. and J.D. Tygar, "Why Johnny Can't Encrypt: A		Whitten, A. and J.D. Tygar, "Why Johnny Can't Encrypt: A
	Usability Evaluation of PGP 5.0", Proceedings of the 8th		Usability Evaluation of PGP 5.0", Proceedings of the 8th
	USENIX Security Symposium, August 1999,		USENIX Security Symposium, August 1999,
	<https://www.usenix.org/legacy/publications/library/		<https://www.usenix.org/legacy/publications/library/
	skipping to change at line 1150 ¶		skipping to change at line 1150 ¶
	Acknowledgements		Acknowledgements
	Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan		Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan
	Johnston, Hadriel Kaplan (Section 4.2.1), Matthew Kaufman, Martin		Johnston, Hadriel Kaplan (Section 4.2.1), Matthew Kaufman, Martin
	Thomson, Magnus Westerlund.		Thomson, Magnus Westerlund.
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
	RTFM, Inc.		Mozilla
	2064 Edgewood Drive
	Palo Alto, CA 94303
	United States of America
	Phone: +1 650 678 2350
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
End of changes. 15 change blocks.
	50 lines changed or deleted		46 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/