Subject: [rtcweb] Review of draft-rescorla-rtcweb-security

From: Bernard Aboba <[email-masked]>
Date: Sat, 11 Jun 2011 14:40:20 -0700

Review of draft-rescorla-rtcweb-security

Overall, a reasonable -00 that needs expanded coverage in a number of areas before it
can be considered for adoption as a WG document. 

Comments below: 

   The Real-Time Communications on the Web (RTC-Web) working group is
   tasked with standardizing protocols for real-time communications
   between Web browsers.  The two major use cases for RTC-Web technology
   are real-time audio and/or video calls and direct data transfer.

[BA] Today, Web-based realtime communications technology is widely
deployed (albeit proprietary), and one of the major use cases is
Web conferencing (e.g. WebEx).  So this is probably deserving
of consideration although this may not be convenient given the
discussion that follows. 

   More subtly, if the
   exposed APIs allow the server to instruct the browser to send
   arbitrary content, then they can be used to bypass firewalls or mount
   denial of service attacks.  Any successful system will need to be
   resistant to this and other attacks.

[BA] This would include things like denial of service attacks on
public service answering points (PSAPs). 

   Conventionally, we refer to either WEB ATTACKERS, who are able to
   induce you to visit their sites but do not control the network, and
   NETWORK ATTACKERS, who are able to control your network.  Network
   attackers correspond to the [RFC3552] "Internet Threat Model".  In
   general, it is desirable to build a system which is secure against
   both kinds of attackers, but realistically many sites do not run
   HTTPS [RFC2818] and so our ability to defend against network
   attackers is necessarily somewhat limited.  Most of the rest of this
   section is devoted to web attackers, with the assumption that
   protection against network attackers is provided by running HTTPS.

[BA] I'd suggest that the issue of "privacy leakage" also be mentioned, even
though this is a much nastier problem that is largely outside the scope of
the RTCWEB WG:
http://www.w3.org/2011/track-privacy/slides/wills.pdf

The issue of privacy may also be relevant in other contexts such as
the potential creation of a Javascript API to return the interface addresses (e.g.
for use by ICE).  My take is that the document should take a position on this
(e.g. that such an extension would be OK or not). 

3.3.  Bypassing SOP: CORS, WebSockets, and consent to communicate

   While SOP serves an important security function, it also makes it
   inconvenient to write certain classes of applications.  In
   particular, mash-ups, in which a script from origin A uses resources
   from origin B, can only be achieved via a certain amount of hackery.
   The W3C Cross-Origin Resource Sharing (CORS) spec [CORS] is a
   response to this demand.  

[BA] It probably should be noted that there are other ways around
the same ORIGIN policy that are widely used today.  These
include Javascript libraries as well as general-purpose 
BOSH connection managers.

4.1.  Access to Local Devices

   Arguably, origin is not fine-grained enough.  Consider the situation
   where Alice visits a site and authorizes it to make a single call.
   If consent is expressed solely in terms of origin, then at any future
   visit to that site (including one induced via mash-up or ad network),
   the site can bug Alice's computer.  While in principle Alice could
   grant and then revoke the privilege, in practice privileges
   accumulate; if we are concerned about this attack, something else is
   needed.  There are a number of potential countermeasures to this sort
   of issue.

[BA] Not only can they bug Alice's computer, but the site could also
do other things like making a bogus emergency call. 

4.2.2.  Masking

   Once consent is verified, there still is some concern about
   misinterpretation attacks as described by Huang et al.[huang-w2sp].
   As long as communication is limited to UDP, then this risk is
   probably limited, thus masking is not required for UDP.  

[BA] Are you saying that the browser should be able to send arbitrary
UDP traffic once "consent" is granted?  

4.2.3.  Backward Compatibility

   A requirement to use ICE limits compatibility with legacy non-ICE
   clients.  It seems unsafe to completely remove the requirement for
   some check, but it might be possible to merely require a one-sided
   check where the legacy client was a STUN responder.  It's unclear
   whether that is in fact simpler than doing ICE-Lite.

[BA] This section needs to be expanded to provide more in depth
discussion of backward compatibility issues and potential approaches,
which might include:

a. RTCP-based approaches (e.g. no ICE).  
b. STUN without ICE extensions

Since each of these approaches has weaknesses, it would be useful to
make clear what attacks can be launched against them and what
mitigating measures might be available, along with a discussion
of their effectiveness and an overall recommendation.

4.3.  Communications Security

   Technology for providing this
   service (for instance, DTLS [RFC4347] and DTLS-SRTP [RFC5763]) is
   well understood.  However, we must examine this technology to the
   RTC-Web context, where the threat model is somewhat different.

[BA] As suggested in draft-johnston-rtcweb-media-privacy, the threat
model is not the only potential issue in the RTCWEB context -- there
is also the problem of dependency on (non-standardized) signaling.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Jun 2011 12:26:50 -0600

> UDP traffic once "consent" is granted?  

I could be very confused about this but .... I think it is OK with UDP (after consent is given on the 5 tuple) or even with TLS over TCP. I'm not sure how long the consent should last. The only place I know of where this is a problem is when there are middle boxes that intercept traffic that is not addressed to them. I don't think this happens to the existing UDP based protocols. Not sure if I have this right but I hope some discussions ensues....