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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------