Subject: [rtcweb] comments on draft-ietf-rtcweb-security-01

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Nov 2011 18:12:39 -0500

Section 4.2.4 says that, to provide IP location privacy, the 
implementation should not start ICE until the callee has answered. I 
disagree that this is necessary in most cases. In voip systems where 
there is some kind of social graph governing consent for communications 
(e.g., I can only be called by buddies), it is sufficient to perform the 
check based on caller identity prior to ICE exchanges. The 
recommendation you make only applies to cases where incoming calls alert 
users without prior authorization checks. Note also that non-social 
graph checks (like callers with high calling volumes) can also suffice.

Section 4.2.4 would also seem to imply a security requirement that there 
be a way to ask the browser to only use TURN candidaets but there is no 
corresponding MUST about it (though I see it comes much later in the 
appendix).

Section 4.3 - firstly, the section is not at all clear about the attack 
you are concerning yourself with here. Clearly it is not "the calling 
service is malicious and stops me from making calls". This attack is 
unpreventable. The unstated requirement is that there is a desire that a 
site is trusted to handle all aspects of the call (setup, identity, 
authentication, etc.) but is not trusted to have access to the media 
content of the call. I think serious justification is needed about why 
this class of attack is important. There is no analog I can think of in 
the web today; if a site becomes malicious, any content I have sent to 
it is compromised.

Section 4.3.1 - I think the case against SDES is over-stated. One can 
certainly design systems which do not log these keys. I agree care must 
be taken to do so, but certainly there is precedent for sites have 
access to user content which is highly sensitive and must not be logged 
or revealed in general. User passwords (collected through forms sent 
over HTTPS), credit cards, and PIN codes come to mind. I would assert 
that the risks of compromise of a credit card is far higher than for the 
keys for some call I made to my grandma.

I think there are a few other topics worthy of discussion in the draft. 
One topic is providing users clear indications that they are in a call, 
and that their mic and/or camera are active. browser generated 
indicators in the browser chrome can help mitigate against attacks from 
malicious sites that have garnered user consent. There are also 
human-factor "security" issues involved too - we've all heard horror 
stories about users that are in video calls and browse away to other 
apps, forgetting they are transmitting video... you mention this in the 
appendix but there is no threat analysis of it.

Another topic is launching DOS attacks against the IP network itself by 
sending video traffic without sufficient congestion control.

Appendix A.1.1:

>  Other users:  RTC-Web peers whose origin we can verify
>       cryptographically (optimally via DTLS-SRTP).

What does it mean to "verify the origin"? DTLS-SRTP will not provide an 
authenticated identity in the rtcweb context (not one of the form 
user@domain for example).

Appendix A: I think the architecture needs to more clearly separate the 
browser itself from the JS/HTML running in the browser. As I read the 
descriptions in A.2.1 it was not clear to me at all whether you were 
implying that the browser would contact the identity service, or whether 
the JS would do so. Which did you intend? From reading further I think 
you imply that the BROWSER itself is to determine the identity of the user?

In such a case I strongly object to this. Identity is something that is 
entirely the domain of the application and should be out of scope for 
the browser itself. If I am reading right, you are proposing that the 
browser itself implement identity verification assuming a fixed set of 
identity protocols? I strongly object to this as well. This would 
effectively require all websites providing real-time comms to use the 
specified identity protocols, as well as the model you espouse (of 
separating site identity from user identity). The Internet of today is 
far from that.

Section A.3.5: I think it will not surprise you one bit that I think 
SDES/SRTP is MUST implement. I would also strike "for backwards 
compatibility purposes". It is up to the app to decide for what purpose.

Minor:

Section 3 is entitled the browser threat model but its mostly focused on 
describing the browser sandbox model.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net