[rtcweb] Review of draft-ietf-rtcweb-security-01.txt (part I)

[Bernard Aboba <[e-mail]>]

Section 1

[BA] In addition to introducing the threat model, I would suggest that this section reference the Use Case and Overview documents, as well as providing an overview of the rest of the document.   

Section 4.1
   In order for the user
   to make an intelligent decision about whether to allow a call (and
   hence his camera and microphone input to be routed somewhere), he
   must understand either who is requesting access, where the media is
   going, or both.  So, for instance, one might imagine that at the time
   access to camera and microphone is requested, the user is shown a
   dialog that says "site X has requested access to camera and
   microphone, yes or no" (though note that this type of in-flow
   interface violates one of the guidelines in Section 3).  The user's
   decision will of course be based on his opinion of Site X. However,
   as discussed below, this is a complicated concept.

[BA] I would suggest that this paragraph needs to be restructured.  

The question of "camera and microphone input" is a device access question,
that relates to "who is requesting access", whereas "allowing a call... to be routed somewhere"
is relevant to "where the media is going." 

While the last two sentences of the paragraph relate to the device access question,
the media question is not introduced in this section.  While this question is (partially) addressed in
Sections 4.1.1.1, 4.1.1.2 and 4.1.1.3, I would like to see some basic discussion of the 
problem in Section 4.1. 

For example, the nature of the "where the media is going" problem could be introduced, talking
about identification mechanisms and the trust relationships that they might depend on.  Without
this, it is somewhat hard to place Sections 4.1.1.1, 4.1.1.2 and 4.1.1.3 in context. 

Section 4.1.1.1

A key aspect of this scenario is that the user is designating the callee, not the site.  While the application might or might not
be carrying out the user's wishes or doing something nefarious, the caller at least has an expectation of what should happen. 
For example, if the caller asks the service to call his or her mother and someone else answers the phone, there is some probability
that the caller will recognize this, whereas if the service decides who should be called, then no such expectations are in place.

Section 4.1.1.2

the user's expectation is that they are calling the site they're actually visiting.

[BA] Rather than just talking about the device access issue, I'd suggest that the "media routing" issue also be addressed here. 

This can be quite a complex issue to deal with, particularly in a situation where the destination is an E.164 number.   
In such a situation, the best that might be achievable is to provide the user with an assertion of the destination or provider,
as well as information on the trustworthiness of that assertion.  For example, a site whose identity has been verified
by HTTPS might assert that a given E.164 number is being called;  or the identity of the media endpoint might be cryptographically
verified (e.g. a service-provider SBC) so that the user might not know who is being called, but they might know
that the call is being handled by a particular service-provider. 

Personally, it seems that independently verifying the media destination and device access and explaining this to the user may be 
futile in many cases, in that the user will be presented with unrelated and (possibly irrelevant) information on which to make
a judgment.  Ultimately, simplicity may be the best guide, and if we're looking for "one throat to choke" that throat is most
likely to be the site delivering the web page. 

Section 4.1.2


   While this is primarily a question not for IETF, it should be clear
   that there is no really good answer.  In general, if you cannot trust
   the site which you have authorized for calling not to bug you then
   your security situation is not really ideal.  It is RECOMMENDED that
   browsers have explicit (and obvious) indicators that they are in a
   call in order to mitigate this risk.

[BA] This is a very important section, since the usage scenario presented is very challenging -- the user could be potentially 
mislead not only as to the entity that is providing the code (e.g. third party vs. first party), but also the media endpoint.  
This potentially takes the worst aspects of today's third party "tracking" scenarios to a new level -- 
audio/video surveillance by unknown third parties.  

I'd like to see more potential solutions explored here.  For example, if the site isn't trustworthy, it may be useful to explore
the potential use of trusted third parties.  













> From: [e-mail]
> To: [e-mail]
> Date: Sun, 30 Oct 2011 21:56:47 -0700
> CC: [e-mail]
> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.
> 
> 	Title           : Security Considerations for RTC-Web
> 	Author(s)       : Eric Rescorla
> 	Filename        : draft-ietf-rtcweb-security-01.txt
> 	Pages           : 36
> 	Date            : 2011-10-30
> 
>    The Real-Time Communications on the Web (RTC-Web) working group is
>    tasked with standardizing protocols for real-time communications
>    between Web browsers.  The major use cases for RTC-Web technology are
>    real-time audio and/or video calls, Web conferencing, and direct data
>    transfer.  Unlike most conventional real-time systems (e.g., SIP-
>    based soft phones) RTC-Web communications are directly controlled by
>    some 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 RTC-Web threat model and defines an architecture which
>    provides security within that threat model.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-01.txt
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb