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/