draft-ietf-rtcweb-security-09.txt		draft-ietf-rtcweb-security-10.txt
	RTC-Web E. Rescorla		RTC-Web E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track October 29, 2017		Intended status: Standards Track January 22, 2018
	Expires: May 2, 2018		Expires: July 26, 2018
	Security Considerations for WebRTC		Security Considerations for WebRTC
	draft-ietf-rtcweb-security-09		draft-ietf-rtcweb-security-10
	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.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 May 2, 2018.		This Internet-Draft will expire on July 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8		4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8
	4.1.2. Calling Scenarios and User Expectations . . . . . . . 8		4.1.2. Calling Scenarios and User Expectations . . . . . . . 8
	4.1.2.1. Dedicated Calling Services . . . . . . . . . . . 8		4.1.2.1. Dedicated Calling Services . . . . . . . . . . . 8
	4.1.2.2. Calling the Site You're On . . . . . . . . . . . 9		4.1.2.2. Calling the Site You're On . . . . . . . . . . . 9
	4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 9		4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 9
	4.1.4. Security Properties of the Calling Page . . . . . . . 11		4.1.4. Security Properties of the Calling Page . . . . . . . 11
	4.2. Communications Consent Verification . . . . . . . . . . . 12		4.2. Communications Consent Verification . . . . . . . . . . . 12
	4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13		4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 13		4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 13
	4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15		4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 14
	4.3. Communications Security . . . . . . . . . . . . . . . . . 15		4.3. Communications Security . . . . . . . . . . . . . . . . . 15
	4.3.1. Protecting Against Retrospective Compromise . . . . . 16		4.3.1. Protecting Against Retrospective Compromise . . . . . 16
	4.3.2. Protecting Against During-Call Attack . . . . . . . . 17		4.3.2. Protecting Against During-Call Attack . . . . . . . . 17
	4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . 17		4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . 17
	4.3.2.2. Short Authentication Strings . . . . . . . . . . 18		4.3.2.2. Short Authentication Strings . . . . . . . . . . 18
	4.3.2.3. Third Party Identity . . . . . . . . . . . . . . 19		4.3.2.3. Third Party Identity . . . . . . . . . . . . . . 18
	4.3.2.4. Page Access to Media . . . . . . . . . . . . . . 19		4.3.2.4. Page Access to Media . . . . . . . . . . . . . . 19
	4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20		4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20
	4.4. Privacy Considerations . . . . . . . . . . . . . . . . . 20		4.4. Privacy Considerations . . . . . . . . . . . . . . . . . 20
	4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . 20		4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . 20
	4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . 20		4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . 20
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 21		5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	7. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . 21		9.1. Normative References . . . . . . . . . . . . . . . . . . 21
			9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The Real-Time Communications on the Web (RTCWEB) working group is		The Real-Time Communications on the Web (RTCWEB) working group is
	tasked with standardizing protocols for real-time communications		tasked with standardizing protocols for real-time communications
	between Web browsers, generally called "WebRTC"		between Web browsers, generally called "WebRTC"
	[I-D.ietf-rtcweb-overview]. The major use cases for WebRTC		[I-D.ietf-rtcweb-overview]. The major use cases for WebRTC
	technology are real-time audio and/or video calls, Web conferencing,		technology are real-time audio and/or video calls, Web conferencing,
	and direct data transfer. Unlike most conventional real-time		and direct data transfer. Unlike most conventional real-time
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Note that this attack does not depend on the media being insecure.		Note that this attack does not depend on the media being insecure.
	Because the call is to the attacker, it is also encrypted to him.		Because the call is to the attacker, it is also encrypted to him.
	Moreover, it need not be executed immediately; the attacker can		Moreover, it need not be executed immediately; the attacker can
	"infect" the origin semi-permanently (e.g., with a web worker or a		"infect" the origin semi-permanently (e.g., with a web worker or a
	popped-up window that is hidden under the main window.) and thus be		popped-up window that is hidden under the main window.) and thus be
	able to bug me long after I have left the infected network. This		able to bug me long after I have left the infected network. This
	risk is created by allowing calls at all from a page fetched over		risk is created by allowing calls at all from a page fetched over
	HTTP.		HTTP.
	Even if calls are only possible from HTTPS sites, if the site embeds		Even if calls are only possible from HTTPS [RFC2818] sites, if the
	active content (e.g., JavaScript) that is fetched over HTTP or from		site embeds active content (e.g., JavaScript) that is fetched over
	an untrusted site, because that JavaScript is executed in the		HTTP or from an untrusted site, because that JavaScript is executed
	security context of the page [finer-grained]. Thus, it is also		in the security context of the page [finer-grained]. Thus, it is
	dangerous to allow WebRTC functionality from HTTPS origins that embed		also dangerous to allow WebRTC functionality from HTTPS origins that
	mixed content. Note: this issue is not restricted to PAGES which		embed mixed content. Note: this issue is not restricted to PAGES
	contain mixed content. If a page from a given origin ever loads		which contain mixed content. If a page from a given origin ever
	mixed content then it is possible for a network attacker to infect		loads mixed content then it is possible for a network attacker to
	the browser's notion of that origin semi-permanently.		infect the browser's notion of that origin semi-permanently.
	4.2. Communications Consent Verification		4.2. Communications Consent Verification
	As discussed in Section 3.3, allowing web applications unrestricted		As discussed in Section 3.3, allowing web applications unrestricted
	network access via the browser introduces the risk of using the		network access via the browser introduces the risk of using the
	browser as an attack platform against machines which would not		browser as an attack platform against machines which would not
	otherwise be accessible to the malicious site, for instance because		otherwise be accessible to the malicious site, for instance because
	they are topologically restricted (e.g., behind a firewall or NAT).		they are topologically restricted (e.g., behind a firewall or NAT).
	In order to prevent this form of attack as well as cross-protocol		In order to prevent this form of attack as well as cross-protocol
	attacks it is important to require that the target of traffic		attacks it is important to require that the target of traffic
	skipping to change at page 13, line 16 ¶		skipping to change at page 13, line 16 ¶
	to receive traffic from a particular sender, and at this time; for		to receive traffic from a particular sender, and at this time; for
	example a malicious site may simply attempt ICE to known servers that		example a malicious site may simply attempt ICE to known servers that
	are using ICE for other sessions. ICE provides this verification as		are using ICE for other sessions. ICE provides this verification as
	well, by using the STUN credentials as a form of per-session shared		well, by using the STUN credentials as a form of per-session shared
	secret. Those credentials are known to the Web application, but		secret. Those credentials are known to the Web application, but
	would need to also be known and used by the STUN-receiving element to		would need to also be known and used by the STUN-receiving element to
	be useful.		be useful.
	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.		ICE keepalives are indications, they will not work here. [RFC7675]
	[I-D.ietf-rtcweb-stun-consent-freshness] describes the mechanism for		describes the mechanism for providing consent freshness.
	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		Where TCP is used the risk is substantial due to the potential
	presence of transparent proxies and therefore if TCP is to be used,		presence of transparent proxies and therefore if TCP is to be used,
	then WebSockets style masking MUST be employed.		then WebSockets style masking MUST be employed.
	Since DTLS (with the anti-chosen plaintext mechanisms required by TLS		Since DTLS (with the anti-chosen plaintext mechanisms required by TLS
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 27 ¶
	4.3. Communications Security		4.3. Communications Security
	Finally, we consider a problem familiar from the SIP world:		Finally, we consider a problem familiar from the SIP world:
	communications security. For obvious reasons, it MUST be possible		communications security. For obvious reasons, it MUST be possible
	for the communicating parties to establish a channel which is secure		for the communicating parties to establish a channel which is secure
	against both message recovery and message modification. (See		against both message recovery and message modification. (See
	[RFC5479] for more details.) This service must be provided for both		[RFC5479] for more details.) This service must be provided for both
	data and voice/video. Ideally the same security mechanisms would be		data and voice/video. Ideally the same security mechanisms would be
	used for both types of content. Technology for providing this		used for both types of content. Technology for providing this
	service (for instance, SRTP [RFC3711], DTLS [RFC4347] and DTLS-SRTP		service (for instance, SRTP [RFC3711], DTLS [RFC6347] and DTLS-SRTP
	[RFC5763]) is well understood. However, we must examine this		[RFC5763]) is well understood. However, we must examine this
	technology to the WebRTC context, where the threat model is somewhat		technology to the WebRTC context, where the threat model is somewhat
	different.		different.
	In general, it is important to understand that unlike a conventional		In general, it is important to understand that unlike a conventional
	SIP proxy, the calling service (i.e., the Web server) controls not		SIP proxy, the calling service (i.e., the Web server) controls not
	only the channel between the communicating endpoints but also the		only the channel between the communicating endpoints but also the
	application running on the user's browser. While in principle it is		application running on the user's browser. While in principle it is
	possible for the browser to cut the calling service out of the loop		possible for the browser to cut the calling service out of the loop
	and directly present trusted information (and perhaps get consent),		and directly present trusted information (and perhaps get consent),
	skipping to change at page 20, line 37 ¶		skipping to change at page 20, line 32 ¶
	4.4. Privacy Considerations		4.4. Privacy Considerations
	4.4.1. Correlation of Anonymous Calls		4.4.1. Correlation of Anonymous Calls
	While persistent endpoint identifiers can be a useful security		While persistent endpoint identifiers can be a useful security
	feature (see Section 4.3.2.1 they can also represent a privacy threat		feature (see Section 4.3.2.1 they can also represent a privacy threat
	in settings where the user wishes to be anonymous. WebRTC provides a		in settings where the user wishes to be anonymous. WebRTC provides a
	number of possible persistent identifiers such as DTLS certificates		number of possible persistent identifiers such as DTLS certificates
	(if they are reused between connections) and RTCP CNAMES (if		(if they are reused between connections) and RTCP CNAMES (if
	generated according to [RFC6222] rather than the privacy preserving		generated according to [RFC6222] rather than the privacy preserving
	mode of [I-D.ietf-avtcore-6222bis]). In order to prevent this type		mode of [RFC7022]). In order to prevent this type of correlation,
	of correlation, browsers need to provide mechanisms to reset these		browsers need to provide mechanisms to reset these identifiers (e.g.,
	identifiers (e.g., with the same lifetime as cookies). Moreover, the		with the same lifetime as cookies). Moreover, the API should provide
	API should provide mechanisms to allow sites intended for anonymous		mechanisms to allow sites intended for anonymous calling to force the
	calling to force the minting of fresh identifiers. In addition, IP		minting of fresh identifiers. In addition, IP addresses can be a
	addresses can be a source of call linkage		source of call linkage [I-D.ietf-rtcweb-ip-handling]
	[I-D.ietf-rtcweb-ip-handling]
	4.4.2. Browser Fingerprinting		4.4.2. Browser Fingerprinting
	Any new set of API features adds a risk of browser fingerprinting,		Any new set of API features adds a risk of browser fingerprinting,
	and WebRTC is no exception. Specifically, sites can use the presence		and WebRTC is no exception. Specifically, sites can use the presence
	or absence of specific devices as a browser fingerprint. In general,		or absence of specific devices as a browser fingerprint. In general,
	the API needs to be balanced between functionality and the		the API needs to be balanced between functionality and the
	incremental fingerprint risk.		incremental fingerprint risk.
	5. Security Considerations		5. Security Considerations
	This entire document is about security.		This entire document is about security.
	6. Acknowledgements		6. Acknowledgements
	Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan		Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan
	Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson,		Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson,
	Magnus Westerlund.		Magnus Westerlund.
	7. Changes Since -04		7. IANA Considerations
			There are no IANA considerations.
			8. Changes Since -04
	o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to		o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to
	the IETF WG		the IETF WG
	o Removed discussion of the IFRAMEd advertisement case, since we		o Removed discussion of the IFRAMEd advertisement case, since we
	decided not to treat it specially.		decided not to treat it specially.
	o Added a privacy section considerations section.		o Added a privacy section considerations section.
	o Significant edits to the SAS section to reflect Alan Johnston's		o Significant edits to the SAS section to reflect Alan Johnston's
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 39 ¶
	o Updated the "communications consent" section to reflrect draft-		o Updated the "communications consent" section to reflrect draft-
	ietf.		ietf.
	o Added a section about "malicious peers".		o Added a section about "malicious peers".
	o Added a section describing screen sharing threats.		o Added a section describing screen sharing threats.
	o Assorted editorial changes.		o Assorted editorial changes.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	8.2. Informative References		9.2. Informative References
	[abarth-rtcweb]		[abarth-rtcweb]
	Barth, A., "Prompting the user is security failure", RTC-		Barth, A., "Prompting the user is security failure", RTC-
	Web Workshop, September 2010.		Web Workshop, September 2010.
	[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", January		[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", January
	2014.		2014.
	[cranor-wolf]		[cranor-wolf]
	Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and		Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and
	skipping to change at page 22, line 27 ¶		skipping to change at page 22, line 27 ¶
	[finer-grained]		[finer-grained]
	Barth, A. and C. Jackson, "Beware of Finer-Grained		Barth, A. and C. Jackson, "Beware of Finer-Grained
	Origins", W2SP, 2008, July 2008.		Origins", W2SP, 2008, July 2008.
	[huang-w2sp]		[huang-w2sp]
	Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.		Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
	Jackson, "Talking to Yourself for Fun and Profit", W2SP,		Jackson, "Talking to Yourself for Fun and Profit", W2SP,
	2011, May 2011.		2011, May 2011.
	[I-D.ietf-avtcore-6222bis]
	Begen, A., Perkins, C., Wing, D., and E. Rescorla,
	"Guidelines for Choosing RTP Control Protocol (RTCP)
	Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
	(work in progress), July 2013.
	[I-D.ietf-rtcweb-ip-handling]		[I-D.ietf-rtcweb-ip-handling]
	Uberti, J. and G. Shieh, "WebRTC IP Address Handling		Uberti, J. and G. Shieh, "WebRTC IP Address Handling
	Requirements", draft-ietf-rtcweb-ip-handling-04 (work in		Requirements", draft-ietf-rtcweb-ip-handling-04 (work in
	progress), July 2017.		progress), July 2017.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-18		Browser-based Applications", draft-ietf-rtcweb-overview-19
	(work in progress), March 2017.		(work in progress), November 2017.
	[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-12 (work in progress), June 2016.		rtcweb-security-arch-13 (work in progress), October 2017.
	[I-D.ietf-rtcweb-stun-consent-freshness]
	Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson,
	"STUN Usage for Consent Freshness", draft-ietf-rtcweb-
	stun-consent-freshness-16 (work in progress), August 2015.
	[I-D.kaufman-rtcweb-security-ui]
	Kaufman, M., "Client Security User Interface Requirements
	for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
	progress), June 2011.
	[kain-conversion]		[kain-conversion]
	Kain, A. and M. Macon, "Design and Evaluation of a Voice		Kain, A. and M. Macon, "Design and Evaluation of a Voice
	Conversion Algorithm based on Spectral Envelope Mapping		Conversion Algorithm based on Spectral Envelope Mapping
	and Residual Prediction", Proceedings of ICASSP, May		and Residual Prediction", Proceedings of ICASSP, May
	2001, May 2001.		2001, May 2001.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000, <https://www.rfc-		DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
	editor.org/info/rfc2818>.		editor.org/info/rfc2818>.
	skipping to change at page 23, line 45 ¶		skipping to change at page 23, line 30 ¶
	[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely		[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
	Available Credentials (SACRED) - Credential Server		Available Credentials (SACRED) - Credential Server
	Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004,		Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004,
	<https://www.rfc-editor.org/info/rfc3760>.		<https://www.rfc-editor.org/info/rfc3760>.
	[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,		Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
	January 2006, <https://www.rfc-editor.org/info/rfc4251>.		January 2006, <https://www.rfc-editor.org/info/rfc4251>.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
	<https://www.rfc-editor.org/info/rfc4347>.
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,		Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
	<https://www.rfc-editor.org/info/rfc4568>.		<https://www.rfc-editor.org/info/rfc4568>.
	[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,		Traversal for Offer/Answer Protocols", RFC 5245,
	DOI 10.17487/RFC5245, April 2010, <https://www.rfc-		DOI 10.17487/RFC5245, April 2010, <https://www.rfc-
	editor.org/info/rfc5245>.		editor.org/info/rfc5245>.
	skipping to change at page 24, line 32 ¶		skipping to change at page 24, line 15 ¶
	[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:		[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
	Media Path Key Agreement for Unicast Secure RTP",		Media Path Key Agreement for Unicast Secure RTP",
	RFC 6189, DOI 10.17487/RFC6189, April 2011,		RFC 6189, DOI 10.17487/RFC6189, April 2011,
	<https://www.rfc-editor.org/info/rfc6189>.		<https://www.rfc-editor.org/info/rfc6189>.
	[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for		[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
	Choosing RTP Control Protocol (RTCP) Canonical Names		Choosing RTP Control Protocol (RTCP) Canonical Names
	(CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011,		(CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011,
	<https://www.rfc-editor.org/info/rfc6222>.		<https://www.rfc-editor.org/info/rfc6222>.
			[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011, <https://www.rfc-		DOI 10.17487/RFC6454, December 2011, <https://www.rfc-
	editor.org/info/rfc6454>.		editor.org/info/rfc6454>.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	RFC 6455, DOI 10.17487/RFC6455, December 2011,		RFC 6455, DOI 10.17487/RFC6455, December 2011,
	<https://www.rfc-editor.org/info/rfc6455>.		<https://www.rfc-editor.org/info/rfc6455>.
			[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
			"Guidelines for Choosing RTP Control Protocol (RTCP)
			Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
			September 2013, <https://www.rfc-editor.org/info/rfc7022>.
			[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
			Thomson, "Session Traversal Utilities for NAT (STUN) Usage
			for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
			October 2015, <https://www.rfc-editor.org/info/rfc7675>.
	[SWF] Adobe, "SWF File Format Specification Version 19", April		[SWF] Adobe, "SWF File Format Specification Version 19", April
	2013.		2013.
	[whitten-johnny]		[whitten-johnny]
	Whitten, A. and J. Tygar, "Why Johnny Can't Encrypt: A		Whitten, A. and J. 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, 1999, August 1999.		USENIX Security Symposium, 1999, August 1999.
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
End of changes. 22 change blocks.
	59 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/