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

[Bug 20806] Section 15 (Security Considerations) is empty

From: <bugzilla@jessica.w3.org>
Date: Fri, 25 Apr 2014 07:16:40 +0000
To: public-webrtc@w3.org
Message-ID: <bug-20806-4991-46rMQylWD9@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20806

Harald Alvestrand <harald@alvestrand.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |harald@alvestrand.no
           Assignee|public-webrtc@w3.org        |harald@alvestrand.no

--- Comment #1 from Harald Alvestrand <harald@alvestrand.no> ---
A proposed text, based on a proposal sent to the list on April 23 and
subsequent discussion:

Security considerations

This section is non-normative; it specifies no new behaviour, but instead
summarizes information already present in other parts of the specification.

This document extends the Web platform with the ability to set up real time,
direct communication between browsers and other devices, including other
browsers.
This means that data and media can be shared between applications running in
different browsers, or between an application running in a browser and
something that is not a browser, something that is an extension to the usual
barriers in the Web model against sending data between entities with different
origins.


The WebRTC specification provides no user prompts or chrome indicators for
communication; it assumes that once the Web page has been allowed to access
media, it is free to share that media with other entities as it chooses.

A mechanism, PeerIdentity, is provided that gives Javascript the option of
requesting media that the Javascript cannot access, but can only be sent to
certain other entities.

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Received on Friday, 25 April 2014 07:16:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC