draft-ietf-rtcweb-security-08.txt   draft-ietf-rtcweb-security-09.txt 
RTC-Web E. Rescorla RTC-Web E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track February 26, 2015 Intended status: Standards Track October 29, 2017
Expires: August 30, 2015 Expires: May 2, 2018
Security Considerations for WebRTC Security Considerations for WebRTC
draft-ietf-rtcweb-security-08 draft-ietf-rtcweb-security-09
Abstract Abstract
The Real-Time Communications on the Web (RTCWEB) working group is WebRTC is a protocol suite for use with real-time applications that
tasked with standardizing protocols for real-time communications can be deployed in browsers - "real time communication on the Web".
between Web browsers, generally called "WebRTC". The major use cases This document defines the WebRTC threat model and analyzes the
for WebRTC technology are real-time audio and/or video calls, Web security threats of WebRTC in that model.
conferencing, and direct data transfer. Unlike most conventional
real-time systems (e.g., SIP-based soft phones) WebRTC communications
are directly controlled by a Web server, which poses new security
challenges. For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call. Unrestricted access
to such an API would allow any site which a user visited to "bug" a
user's computer, capturing any activity which passed in front of
their camera. This document defines the WebRTC threat model and
analyzes the security threats of WebRTC in that model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 30, 2015. This Internet-Draft will expire on May 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2017 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 33 skipping to change at page 2, line 23
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Browser Threat Model . . . . . . . . . . . . . . . . . . 4 3. The Browser Threat Model . . . . . . . . . . . . . . . . . . 4
3.1. Access to Local Resources . . . . . . . . . . . . . . . . 5 3.1. Access to Local Resources . . . . . . . . . . . . . . . . 5
3.2. Same Origin Policy . . . . . . . . . . . . . . . . . . . 6 3.2. Same Origin Policy . . . . . . . . . . . . . . . . . . . 5
3.3. Bypassing SOP: CORS, WebSockets, and consent to 3.3. Bypassing SOP: CORS, WebSockets, and consent to
communicate . . . . . . . . . . . . . . . . . . . . . . . 6 communicate . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security for WebRTC Applications . . . . . . . . . . . . . . 7 4. Security for WebRTC Applications . . . . . . . . . . . . . . 7
4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 7 4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 7
4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8 4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8
4.1.2. Calling Scenarios and User Expectations . . . . . . . 9 4.1.2. Calling Scenarios and User Expectations . . . . . . . 8
4.1.2.1. Dedicated Calling Services . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 14 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 13
4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15 4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . 21 4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
7. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21 7. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.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 5, line 26 skipping to change at page 5, line 16
(TCB) both from the user's perspective and to some extent from the (TCB) both from the user's perspective and to some extent from the
server's. While HTML and JavaScript (JS) provided by the server can server's. While HTML and JavaScript (JS) provided by the server can
cause the browser to execute a variety of actions, those scripts cause the browser to execute a variety of actions, those scripts
operate in a sandbox that isolates them both from the user's computer operate in a sandbox that isolates them both from the user's computer
and from each other, as detailed below. and from each other, as detailed below.
Conventionally, we refer to either WEB ATTACKERS, who are able to Conventionally, we refer to either WEB ATTACKERS, who are able to
induce you to visit their sites but do not control the network, and induce you to visit their sites but do not control the network, and
NETWORK ATTACKERS, who are able to control your network. Network NETWORK ATTACKERS, who are able to control your network. Network
attackers correspond to the [RFC3552] "Internet Threat Model". Note attackers correspond to the [RFC3552] "Internet Threat Model". Note
that for HTTP traffic, a network attacker is also a Web attacker, that for non-HTTPS traffic, a network attacker is also a Web
since it can inject traffic as if it were any non-HTTPS Web site. attacker, since it can inject traffic as if it were any non-HTTPS Web
Thus, when analyzing HTTP connections, we must assume that traffic is site. Thus, when analyzing HTTP connections, we must assume that
going to the attacker. traffic is going to the attacker.
3.1. Access to Local Resources 3.1. Access to Local Resources
While the browser has access to local resources such as keying While the browser has access to local resources such as keying
material, files, the camera and the microphone, it strictly limits or material, files, the camera and the microphone, it strictly limits or
forbids web servers from accessing those same resources. For forbids web servers from accessing those same resources. For
instance, while it is possible to produce an HTML form which will instance, while it is possible to produce an HTML form which will
allow file upload, a script cannot do so without user consent and in allow file upload, a script cannot do so without user consent and in
fact cannot even suggest a specific file (e.g., /etc/passwd); the fact cannot even suggest a specific file (e.g., /etc/passwd); the
user must explicitly select the file and consent to its upload. user must explicitly select the file and consent to its upload.
skipping to change at page 7, line 39 skipping to change at page 7, line 31
are two basic conceptual models: are two basic conceptual models:
1. You are sending your media to entity A because you want to talk 1. You are sending your media to entity A because you want to talk
to Entity A (e.g., your mother). to Entity A (e.g., your mother).
2. Entity A (e.g., a calling service) asks to access the user's 2. Entity A (e.g., a calling service) asks to access the user's
devices with the assurance that it will transfer the media to devices with the assurance that it will transfer the media to
entity B (e.g., your mother) entity B (e.g., your mother)
In either case, identity is at the heart of any consent decision. In either case, identity is at the heart of any consent decision.
Moreover, identity is all that the browser can meaningfully enforce; Moreover, the identity of the party the browser is connecting to is
if you are calling A, A can simply forward the media to C. all that the browser can meaningfully enforce; if you are calling A,
Similarly, if you authorize A to place a call to B, A can call C A can simply forward the media to C. Similarly, if you authorize A
instead. In either case, all the browser is able to do is verify and to place a call to B, A can call C instead. In either case, all the
check authorization for whoever is controlling where the media goes. browser is able to do is verify and check authorization for whoever
The target of the media can of course advertise a security/privacy is controlling where the media goes. The target of the media can of
policy, but this is not something that the browser can enforce. Even course advertise a security/privacy policy, but this is not something
so, there are a variety of different consent scenarios that motivate that the browser can enforce. Even so, there are a variety of
different technical consent mechanisms. We discuss these mechanisms different consent scenarios that motivate different technical consent
in the sections below. mechanisms. We discuss these mechanisms in the sections below.
It's important to understand that consent to access local devices is It's important to understand that consent to access local devices is
largely orthogonal to consent to transmit various kinds of data over largely orthogonal to consent to transmit various kinds of data over
the network (see Section 4.2. Consent for device access is largely a the network (see Section 4.2). Consent for device access is largely
matter of protecting the user's privacy from malicious sites. By a matter of protecting the user's privacy from malicious sites. By
contrast, consent to send network traffic is about preventing the contrast, consent to send network traffic is about preventing the
user's browser from being used to attack its local network. Thus, we user's browser from being used to attack its local network. Thus, we
need to ensure communications consent even if the site is not able to need to ensure communications consent even if the site is not able to
access the camera and microphone at all (hence WebSockets's consent access the camera and microphone at all (hence WebSockets's consent
mechanism) and similarly we need to be concerned with the site mechanism) and similarly we need to be concerned with the site
accessing the user's camera and microphone even if the data is to be accessing the user's camera and microphone even if the data is to be
sent back to the site via conventional HTTP-based network mechanisms sent back to the site via conventional HTTP-based network mechanisms
such as HTTP POST. such as HTTP POST.
4.1.1. Threats from Screen Sharing 4.1.1. Threats from Screen Sharing
skipping to change at page 20, line 47 skipping to change at page 20, line 41
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 [I-D.ietf-avtcore-6222bis]). In order to prevent this type
of correlation, browsers need to provide mechanisms to reset these of correlation, browsers need to provide mechanisms to reset these
identifiers (e.g., with the same lifetime as cookies). Moreover, the identifiers (e.g., with the same lifetime as cookies). Moreover, the
API should provide mechanisms to allow sites intended for anonymous API should provide mechanisms to allow sites intended for anonymous
calling to force the minting of fresh identifiers. calling to force the minting of fresh identifiers. In addition, IP
addresses can be a source of call linkage
[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
skipping to change at page 22, line 4 skipping to change at page 21, line 40
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 8. References
8.1. Normative References
[I-D.ietf-rtcweb-overview] 8.1. Normative References
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 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,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[abarth-rtcweb]
Barth, A., "Prompting the user is security failure", RTC-
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]
Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and
L. cranor, "Crying Wolf: An Empirical Study of SSL Warning
Effectiveness", Proceedings of the 18th USENIX Security
Symposium, 2009, August 2009.
[farus-conversion]
Farrus, M., Erro, D., and J. Hernando, "Speaker
Recognition Robustness to Voice Conversion", January 2008.
[finer-grained]
Barth, A. and C. Jackson, "Beware of Finer-Grained
Origins", W2SP, 2008, July 2008.
[huang-w2sp]
Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
Jackson, "Talking to Yourself for Fun and Profit", W2SP,
2011, May 2011.
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-rtcweb-ip-handling]
Uberti, J. and G. Shieh, "WebRTC IP Address Handling
Requirements", draft-ietf-rtcweb-ip-handling-04 (work in
progress), July 2017.
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-18
(work in progress), March 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-10 (work in progress), July 2014. rtcweb-security-arch-12 (work in progress), June 2016.
[I-D.ietf-rtcweb-stun-consent-freshness] [I-D.ietf-rtcweb-stun-consent-freshness]
Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson, Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson,
"STUN Usage for Consent Freshness", draft-ietf-rtcweb- "STUN Usage for Consent Freshness", draft-ietf-rtcweb-
stun-consent-freshness-11 (work in progress), December stun-consent-freshness-16 (work in progress), August 2015.
2014.
[I-D.kaufman-rtcweb-security-ui] [I-D.kaufman-rtcweb-security-ui]
Kaufman, M., "Client Security User Interface Requirements Kaufman, M., "Client Security User Interface Requirements
for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
progress), June 2011. progress), June 2011.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [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 ICASSP, May
2001, May 2001.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <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.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July Text on Security Considerations", BCP 72, RFC 3552,
2003. DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
editor.org/info/rfc3552>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[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, April 2004. Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004,
<https://www.rfc-editor.org/info/rfc3760>.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. 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, July 2006. Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<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, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010, <https://www.rfc-
editor.org/info/rfc5245>.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, [RFC5479] Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009. Protocols", RFC 5479, DOI 10.17487/RFC5479, April 2009,
<https://www.rfc-editor.org/info/rfc5479>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Path Key Agreement for Unicast Secure RTP", RFC 6189, Media Path Key Agreement for Unicast Secure RTP",
April 2011. RFC 6189, DOI 10.17487/RFC6189, April 2011,
<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, April 2011. (CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011,
<https://www.rfc-editor.org/info/rfc6222>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
2011. DOI 10.17487/RFC6454, December 2011, <https://www.rfc-
editor.org/info/rfc6454>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
6455, December 2011. RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
[SWF] Adobe, , "SWF File Format Specification Version 19", April [SWF] Adobe, "SWF File Format Specification Version 19", April
2013. 2013.
[abarth-rtcweb]
Barth, A., "Prompting the user is security failure", RTC-
Web Workshop, September 2010.
[cranor-wolf]
Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and
L. cranor, "Crying Wolf: An Empirical Study of SSL Warning
Effectiveness", Proceedings of the 18th USENIX Security
Symposium, 2009, August 2009.
[farus-conversion]
Farrus, M., Erro, D., and J. Hernando, "Speaker
Recognition Robustness to Voice Conversion", January 2008.
[finer-grained]
Barth, A. and C. Jackson, "Beware of Finer-Grained
Origins", W2SP, 2008, July 2008.
[huang-w2sp]
Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
Jackson, "Talking to Yourself for Fun and Profit", 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 ICASSP, May 2001,
May 2001.
[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
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Phone: +1 650 678 2350 Phone: +1 650 678 2350
Email: ekr@rtfm.com Email: ekr@rtfm.com
 End of changes. 44 change blocks. 
108 lines changed or deleted 123 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/