Subject: Re: [rtcweb] Support of SDES in WebRTC

From: Oscar Ohlsson <[email-masked]>
Date: Mon, 2 Apr 2012 14:17:09 +0200

> -----Original Message-----
> From: Gregory Maxwell [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2012 11:59 PM
> To: Oscar Ohlsson; Iñaki Baz Castillo
> Cc: <[email-masked]>
> Subject: RE: [rtcweb] Support of SDES in WebRTC
> 
> Oscar Ohlsson [[email-masked]] 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

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Tue, 03 Apr 2012 20:10:26 +0200

On 3/29/12 11:59 PM, Gregory Maxwell wrote:
>> That's why I wrote "the entire webapp" below. If it was not clear I meant that the
>> - main HTML page
>> are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content).
> 
> 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). 

That's a on-going debate that for many years kept researcher from
working on JS-crypto, but nowdays the value of JS-crypto it's well
recognized with valuable projects working on it.

I think that in 2012 the old
http://www.matasano.com/articles/javascript-cryptography/ on Javascript
crypto can be considered superseded by
http://hellais.wordpress.com/2011/12/27/how-to-improve-javascript-cryptography/
and by the discussion that arised from the OpenPGPJS mailing lists
https://github.com/tanx/SafeWith.me/wiki/FAQ .

The overall result is that it's possible to do securely enough crypto in
javascript and that, as everything, it depends on the way you use it.

So this is a typical out-of-date javascript crypto security
consideration that is practically discussed in all the mailing lists i'm
subscribed about javascript crypto.

But from a pragmatic point of view there are very valuable way to
implement secure Javascript Crypto and browser vendors are supporting
and driving the path of JS-crypto securization.

The cryptographic negotiation can be, and imho should be, pluggable, to
be able to work at application level.
Thunderbird doesn't provide OpenPGP encryption, but Enigmail (as a
plugin) does.

So imho we should leave to the application the ability to improve and
adapt the security mechanisms, given all the context and use-cases that
this WG cannot even forecast.

Do we want rtcweb security working as "a blackbox" or do we want to make
it working also like an "open platform" where it may be possible.

This is not the strongest argument to have also support for SDES-SRTP,
but it's for sure an argument, where the two strongest factor of SDES are:
- simplicity
- interoperability
- opennes (so ability to hook custom crypto key exchange methods, due to
it's simplicity in handling keys relying on TLS transport)

> 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.

That's a not real issue that cannot be fixed in any case, also in case
you are using a bullet-proof native-code VoIP client.
If you local machine compromised there's no mlock/garbage collection
that can protect against memory dumping and memory injection.

Javascript encryption is secure, for most context, as native encryption
and many attacks considered to javascript crypto are attacks present in
native implementation of crypto.

Fabio