W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Security considerations - a proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 23 Apr 2014 13:53:04 +0200
Message-ID: <5357A9A0.9070905@alvestrand.no>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
I've tried to draft a security considerations section for the media 
capture and streams document.
I've been working from the idea that a security considerations section 
should not specify any new technology or features, but give an overview 
of the security issues that are involved in using the functionality, and 
mentioning the features that are particularly important in mitigating 
the risks involved.

Here's my proposed text. Let's do a round of discussion on the list 
before I enter this into the buganizer and from there into the document.

Security considerations
This section is non-normative.

This document extends the Web platform with the ability to set up real 
time, direct communication between browsers and other devices, including 
other browsers.

While a web application already before WebRTC will know the IP address 
to which the application is delivered, setting up communications exposes 
additional information about the browser’s network context to the web 
application, including the set of IP addresses available to the browser 
for WebRTC use.
Some of this information has to be passed to the corresponding party to 
enable the establishment of a communication session.
Revealing IP addresses can leak location and means of connection; this 
can be sensitive. Some mitigation is possible by using relays (for 
instance TURN servers) rather than direct connections between participants.

Since the browser is an active platform executing in a trusted network 
environment (inside the firewall), it is important to limit the damage 
that the browser can do to other units on the local network, and it is 
important to protect data from interception, manipulation and 
modification by untrusted participants.
Mitigations include:

- Always requesting permission to communicate using ICE. This ensures 
that the browser can only send to partners who you have shared 
credentials with.
- Requesting ongoing permission using ICE continued consent. This 
enables a receiver to withdraw consent to receive.
- Requiring encryption of data, with strong per-session keying (DTLS-SRTP).
- Requiring the use of congestion control. This ensures that WebRTC 
cannot be used to flood the network.

These measures are specified in the relevant IETF documents.
The fact of communication cannot be disguised, so must be regarded as 
public information.
Received on Wednesday, 23 April 2014 11:53:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC