Re: [rtcweb] Support of SDES in WebRTC

[Roman Shpount <[e-mail]>]

On Thu, Mar 29, 2012 at 5:59 PM, Gregory Maxwell <[e-mail]>wrote:

> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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 guess what you are saying (and I believe everybody on this list agree) is
that SDES-SRTP in combination with JavaScript signaling negotiation does
not and cannot provide any meaningful security above preventing simple
network sniffing.
_____________
Roman Shpount