Re: [rtcweb] Support of SDES in WebRTC (Javascript Crypto Extensions)

["Fabio Pietrosanti (naif)" <[e-mail]>]

On 3/29/12 11:59 PM, Gregory Maxwell wrote:
> 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). 

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