Subject: [rtcweb] Fwd: Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Jun 2012 09:50:21 -0700

---------- Forwarded message ----------
From: Eric Rescorla <[email-masked]>
Date: Tue, Jun 5, 2012 at 9:35 AM
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-02 and
draft-ietf-rtcweb-security-arch-01 documents
To: "DRUTA, DAN" <[email-masked]>

Dan,

Thanks for your review, comments below.

> I reviewed the latest version of the drafts and below are my comments/suggestions/corrections (not as comprehensive as Mark's).
> In general I think the documents are well written with good references and paint a rather comprehensive picture of the issues to be addressed for rtcweb.
>
> Draft-ietf-rtcweb-security-02
>
> 1.Introduction -  second paragraph after the diagram:
> "Each of their browsers exposes standardized JavaScript calling APIs which are used by the Web server to set up a call between Alice and Bob."
>
>  This statement can be a bit more clear in that the APIs are executed
>  locally (in the user agent) as java script downloaded from the Web
>  Server. The next paragraph eludes to the fact that logic is
>  controlled by the calling service but I think it will be important
>  to distinguish between APIs implemented by the user-agent and
>  APIs/functions implemented by the calling service.

I added "implemented as browser built-ins". Hope this helps.

> 4.1 Access to Local Devices.
> Since this describes the threat I think is important to point out
> the fact that even when the user provides consent it is difficult
> for them to determine the real reason they give the consent to a
> site. Take the scenario in which a site obtains consent from the
> user for an app that captures a clip and saves it on the user's hard
> drive. Later on, if the user gave permanent consent to the site, the
> site can obtain access to the camera for the purpose of streaming
> without the user knowing that. This can be confusing for users even
> if they trust the site.

Right. This is a good example of the gap between the policy the user
wishes to have enforced (my information will be used only for purposes
A and B and not purpose C) and what we can technically enforce (site X
can have my data but they do whatever they want...)

> 4.2 IP location Privacy
> "Note that as soon as the callee sends their ICE candidates, the callee learns the callee's IP addresses."
> This must be "the caller learns the callee's IP address"

Good catch. Fixed.

> 4.3.2.3. Third Party Identity
> "It is possible (see[I-D.rescorla-rtcweb-generic-idp]) to use systems of this type to authenticate RTCWEB calls, linking them to existing user notions of
> identity (e.g., Facebook adjacencies). Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site."
>
> Not to get too much into semantics, I think it is important to make
> the distinction that users are authenticated (using whatever IdP)
> and calls are authorized based on the assertions provided by the Idp
> for the authenticated user.

Good point. Added something. Let me know if you think it helps.

> Draft-ietf-rtcweb-security-arch-01
>
> 1.Introduction
> "The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers."
>
> While there's nothing inaccurate about the statement, I would like to make it more generic because it is more than just communication between web browsers. In my opinion the WEB part in the acronym is all about using the web technologies to enable real time communications.
>
> A proposed edited definition would be "... standardization protocols
> for enabling real-time communications within user-agents using web
> technologies (e.g JavaScript)".

That's an improvement. Accepted.

> I have been trying to identify the appropriate section for a rather controversial requirement:  Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide support to lawful intercept and I think we need to capture these requirements so we can map them to the security architecture.

I think Martin's assessment of the situation here is pretty much right.

-Ekr