Re: [rtcweb] Support of SDES in WebRTC

[Oscar Ohlsson <[e-mail]>]

 
> -----Original Message-----
> From: Gregory Maxwell [mailto:[e-mail]] 
> Sent: Thursday, March 29, 2012 11:59 PM
> To: Oscar Ohlsson; Iñaki Baz Castillo
> Cc: <[e-mail]>
> Subject: RE: [rtcweb] Support of SDES in WebRTC
> 
> Oscar Ohlsson [[e-mail]] wrote:
> > That's why I wrote "the entire webapp" below. If it was not clear I 
> > meant that the
> > - main HTML page
> > - all external CSS files, JavaScript files, images, etc
> > - all XmlHttpRequests
> > - all WebSocket connections
> > are protected with TLS. This is obviously verifiable and 
> it's a feature supported by all modern browsers (no mixed content).
> 
> Even this is insufficient.
> 
> First, even if it is in principle possible to provide 
> adequate cryptographic security inside the JS applications a 
> great many of them won't (for many reasons). We can't 
> eliminate inconsistency in the security of webrtc 
> applications- but we can certainly make it hard to go below
> a certain level of security especially by accident.   In particular,
> if JS applications provide only authentication services (e.g. 
> by giving them access to hashes of the ephemeral session 
> keys, but not the session keys themselves) then a 
> cryptographically-incompetent application can only fail the 
> user by failing to provide the authentication it promised 
> over and above the platform baseline capability.

Yes, and that's exactly why DTLS-SRTP is offered by default.


> 
> With HTTPS applications are currently free to do dumb things 
> (mixed content, esp scripts) but at least the browser can 
> detected this and alerts the user with varying degrees of 
> loudness.  In a SDES/SRTP world the browser will not be 
> generally able to detect insecure behavior by applications- 
> creating something of a lemon market for webrtc based 
> application security. As a resutl its important to narrow the 
> amount of insecurity possible.

If mixed content is in use then SDES is not available. The user would never be 
queried since it's unlikely that he can make that kind of decision.

> 
> This is effectively a repeat of the arguments against 
> supporting plaintext. If plaintext is supported it will be 
> commonly used because it's easiest, because users can't 
> easily tell how insecure their connection is, and because 
> users often don't have a good feel for the threat model (e.g. 
> things like firesheep were _very_ surprising to most people)...
> Because of this the platform should provide the highest level 
> of security that can reasonably be provided in the platform, 
> and that means (among other things) perfect-forward-secrecy- 
> while allowing applications to add things like authentication 
> on top (because while strong ephemerally keyed crypto can be 
> done very low in the stack, meaningful authentication needs 
> layer-7/8 hooks).

I don't understand this argument. Are you saying that SDES would be more commoly used since it's easier? I seriously doubt that. The easiest is to go with default which is DTLS-SRTP. Only in the legacy interop case would it be necessary to turn on SDES.

> 
> There is also the application/library split issue- if a 
> vulnerability is found in a common negotiation procedure what 
> secures users better? Updating a few easily identified 
> browsers / softphone apps?
> or a much larger base of webapps, many of which would be run 
> by security ignorant/clueless people?  (and at least if the 
> webserver is clueful but the client operator is not the app 
> could yell about the insecure client,
> the other way around doesn't work as well).  -   Really, cryptographic
> negotiation is not properly an application feature, it 
> belongs lower in the stack, and many applications that roll 
> their own crypto have done a poor job of it.

The application is not performing any real cryptographic operations. It basically only forwards SDP blobs between the PeerConnection object and the TLS channel. So security is to a very large extent handled by lower layers.

> 
> It's also inadequate on purely technical grounds: Javascript 
> provides no mechanism for working with mlocked memory,  no 
> mechanism to ensure that garbage collected data gets 
> zeroized.  Your crypto app in JS could easily have its long 
> term keying material pulled out of free ram by malware long 
> after it runs, or pulled off the disk from swap.
> The breakneck pace of fancy JIT systems makes it seem 
> unlikely to me that javascript will provide for that any time soon.

I think you're exaggerating here. I don't know the details of how memory managment works in JavaScript but if you start considering malware applications and infected devices then there's probably very little we can do. Quoting I.D.ietf-rtcweb-security-arch, Section 3:

"Conversely, if the browser is compromised, then no security guarantees are possible." 

I would appreciate if you could describe your attack in more detail and explain the assumptions that you make. I suspect that some parts are left out or have been greatly simplified.

Regards,

Oscar

> 
> 
> 
>