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
- [rtcweb] Support of SDES in WebRTC Fabio Pietrosanti (naif)
- Re: [rtcweb] Support of SDES in WebRTC Oscar Ohlsson
- Re: [rtcweb] Support of SDES in WebRTC Bernard Aboba
- Re: [rtcweb] Support of SDES in WebRTC Iñaki Baz Castillo
- Re: [rtcweb] Support of SDES in WebRTC Fabio Pietrosanti (naif)
- Re: [rtcweb] Support of SDES in WebRTC Iñaki Baz Castillo
- Re: [rtcweb] Support of SDES in WebRTC Oscar Ohlsson
- Re: [rtcweb] Support of SDES in WebRTC Iñaki Baz Castillo
- Re: [rtcweb] Support of SDES in WebRTC Gregory Maxwell
- Re: [rtcweb] Support of SDES in WebRTC Roman Shpount
- Re: [rtcweb] Support of SDES in WebRTC Randell Jesup
- Re: [rtcweb] Support of SDES in WebRTC Oscar Ohlsson
- Re: [rtcweb] Support of SDES in WebRTC (Javascrip… Fabio Pietrosanti (naif)