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

"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> Tue, 03 April 2012 18:11 UTC

Return-Path: <lists@infosecurity.ch>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FEA11E80D1 for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 11:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.691
X-Spam-Level:
X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2TFKMBAOoyc for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 11:11:08 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB511E8083 for <rtcweb@ietf.org>; Tue, 3 Apr 2012 11:11:07 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2727412wgb.13 for <rtcweb@ietf.org>; Tue, 03 Apr 2012 11:11:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=NT1BkhRS5AcBCMA+VvBUL5Fjhb6ZqTAysYgHtF2k5g8=; b=hp9eeJkrLoBuF7e9gdUMu1gnsmVC2qQd/MjTumlkiH2ySEQLDe+r3wKalCrwPQ+8rb adKxrspI5+cJFHgaVmyOhbRy/B8nIW/6g8+AlXAYQGhyyktUKWIACH9oBxbbKZC2R7zp /SIMuR9/Iht9rLWybMb1JTBvXht+jr0Z1/OFEG4vRaUd0RhjHFU5P5HrufPTaSZ6nNq8 aM7QHp8UhFvwA0vAAdkyf30UiE/XMXVI4HDPXkCNwlian6zWMScQXezspjxUS7ZKxn+7 enaRjSrIoK8qil4j8ocihrdejpnNSVSsV0xsqG9RrGDrj+oyTa4m5AD5rvIaL/aiHyH2 3mhg==
Received: by 10.180.104.230 with SMTP id gh6mr38336066wib.22.1333476666464; Tue, 03 Apr 2012 11:11:06 -0700 (PDT)
Received: from sonyvaiop13.local (host146-199-static.115-2-b.business.telecomitalia.it. [2.115.199.146]) by mx.google.com with ESMTPS id w10sm72325602wiy.3.2012.04.03.11.10.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 11:11:01 -0700 (PDT)
Sender: Fabio Pietrosanti <naif@infosecurity.ch>
Message-ID: <4F7B3D12.4090406@infosecurity.ch>
Date: Tue, 03 Apr 2012 20:10:26 +0200
From: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F742344.802@infosecurity.ch> <A1B638D2082DEA4092A268AA8BEF294D194602D97D@ESESSCMS0360.eemea.ericsson.se> <CALiegf=GxJ2Ew9v5H4Xfb8q3j=4TFawNu-6uXRXuXK+Vug1e+w@mail.gmail.com>, <A1B638D2082DEA4092A268AA8BEF294D194602DB63@ESESSCMS0360.eemea.ericsson.se> <BCB3F026FAC4C145A4A3330806FEFDA94086731AF7@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA94086731AF7@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm8we9SoREjyxiVMBeYQQM/RP9RJI59jc2qxjqaP7rPp0FiiDHafGqiIsIVyfFhUTdd+rV3
Subject: Re: [rtcweb] Support of SDES in WebRTC (Javascript Crypto Extensions)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 18:11:16 -0000

On 3/29/12 11:59 PM, Gregory Maxwell wrote:
> Oscar Ohlsson [oscar.ohlsson@ericsson.com] 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