Re: [rtcweb] Support of SDES in WebRTC

[Gregory Maxwell <[e-mail]>]

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.

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.