Subject: Re: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Mar 2013 10:22:47 +0100

EKR and WG,

I have reviewed the security draft (-04) as an individual and have the
following comments.

1. Usage of acronym RTCWEB vs WebRTC. I thought we earlier had a
conclusion that we would use WebRTC as the acronym for the complete
solution? Am I remembering incorrectly?

2. I think the introduction should contain some pointer to the overview
draft for reverse lookup purpose if one stumbles on the document.

3. Section 3.1:
Similarly, while Flash SWFs can access the camera and microphone,
   they explicitly require that the user consent to that access.

Can you please expand the SWF acronym and perhaps add a reference?

4. Section 3.2:
Many other resources are accessible but isolated.  For instance,
   while scripts are allowed to make HTTP requests via the
   XMLHttpRequest() API those requests are not allowed to be made to any
   server, but rather solely to the same ORIGIN from whence the script
   came.[RFC6454] (although CORS [CORS] and WebSockets [RFC6455]
   provides a escape hatch from this restriction, as described below.)

This above looks strange around the first period, which is followed by
RFC6454 reference. If is is a new sentence, the main sentence contains
only a reference.

5. Section 3.2
This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks
   on server B via the user's browser, which protects both the user
   (e.g., from misuse of his credentials) and the server (e.g., from DoS
   attack).

I think one can make clear that the server one protects are B in the end
of the sentence. Although it reasonably clear from context, I think
writing it like this:

This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks
   on server B via the user's browser, which protects both the user
   (e.g., from misuse of his credentials) and the server B (e.g., from
   DoS attack).

Is clearer.

6. Section 4.1.1.3:
In both of the previous cases, the user has a direct relationship
   (though perhaps a transient one) with the target of the call.

Is it really the "target of the call" or is it the calling service that
the user has a direct relation ship with?

7. Section 4.2.1:

[[ OPEN ISSUE:  Do we need some way of verifying the expected traffic
   rate, not just consent to receive traffic at all.]]

Regarding this issue, I think you could add something which makes this
not required, namely that by requiring congestion control of all flows
established by the browser, the browser tries to avoid persistent
congestion and any overload attack is less effective. The attack is more
in the vain of reducing any competing flows supported rate to a lower
fair share rate, which in worst case is below what is required to
support the service being the target of the attack.

Thus I think the open issue question is a nice to have, but not required
feature.

8. Section 4.2.4:

I think this document is missing to discuss the privacy threats beyond
IP location privacy? I think that should be added, especially as we are
addressing some issues we know of.

These other threats that we have discussed are associated with anonymous
calling services and linking and fingerprinting browsers or users with
anonymous calls. The threats we do know exist are for example RTCP CNAME
generation, DTLS certifcates, and API fingerprinting. I think these
needs to be raised as a threat.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Oscar Ohlsson <[email-masked]>
Date: Thu, 7 Mar 2013 14:41:42 +0000

Hi Eric,

Some minor comments on draft-ietf-rtcweb-security:

- Abstract

    This document defines the RTC-Web threat model and defines an 
    architecture which provides security within that threat model 

  Isn't the architecture defined in draft-ietf-rtcweb-security-arch?

- Section 4.1.1.3, 3rd paragraph

    However, this obviously presents a privacy challenge, as sites which 
    host advertisements in IFRAMEs often learn very little about whether 
    individual users clicked through to the ads, or even which ads were 
    presented. 
	
  What exactly is the privacy issue here? Is it that the hosting site 
  can eavesdrop on the call between the user and the advertiser since 
  IFRAMEs are not used? 
   
- Section 4.3.1, 3rd paragraph

    In addition, the system MUST NOT provide any APIs to extract either 
    long-term keying material or to directly access any stored traffic keys. 
	
  Does this mean that SDES is out of the picture or does the sentence only 
  apply to DTLS(-SRTP)?

I apologize if any of the points above have already been mentioned by the other reviewers.

Regards,

Oscar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Hardie
> Sent: den 14 februari 2013 17:35
> To: [email-masked]
> Subject: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
> 
> This begins a working group last call for draft-ietf-rtcweb-security.
> Please send comments to the list by March 9, 2013.
> 
> regards,
> 
> Ted, Cullen, Magnus
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb