Re: [rtcweb] Support of SDES in WebRTC

Roman Shpount <roman@telurix.com> Fri, 30 March 2012 03:30 UTC

Return-Path: <roman@telurix.com>
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 C45DA21F86BA for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 20:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.836
X-Spam-Level:
X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gxgS-Va5nC4s for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 20:30:00 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1CB121F86B6 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1051489pbb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=zcFmGmN5ino8f55PlLb9+NBb/F861CdFlDycGAwO9F0=; b=colhwiMXYQay6vaoW3GkZX1KRpDK37J3UT+Ks2jRo0zAv0ZzlYG4bPQs7xrWwhZt+D UgNhoGKoE8xxc8ZpbFNzO3zqsVxm4/SaU6THsztqsiEOIXsq+vbdXRA/FqkqLQKGjwle Zs+2+N/s2dMp+hHozfY6nZjdJ6HuGd8Tlp6fI86rKBom9HVoZ7lIl0sBgmmJ1DF8Sj0N WoiMQTdv3yyeqlU017BeqXoWDul36zgAX+9Hi3rP65pQsjHJAbIuUPm5PUp1774Y+pcC X1pFMcAuZVyqwnI+0sh24LkfBn8otB3VtDXv2/GoTFoBvKr6r+cBwqPclOgZGjhJndp5 D73A==
Received: by 10.68.234.134 with SMTP id ue6mr5434577pbc.14.1333078199709; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i1sm6358918pbj.70.2012.03.29.20.29.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1051459pbb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.196.163 with SMTP id in3mr5481157pbc.118.1333078198064; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA94086731AF7@EMBX01-HQ.jnpr.net>
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>
Date: Thu, 29 Mar 2012 23:29:58 -0400
Message-ID: <CAD5OKxvZNK9SvrZcFhiF6X8VoinUHo8P1ZH0ys8Gw0FMYY4MTg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Gregory Maxwell <gmaxwell@juniper.net>
X-Gm-Message-State: ALoCoQmKRc/7UQtfJuUZ7VvKUNUZ6wuWvykPD6l+VD+IDnfURCldX16pEEC/ZOps7VZjqamfPOPc
Content-Type: multipart/alternative; boundary=e89a8ff1c65a7415ad04bc6d7467
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Support of SDES in WebRTC
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: Fri, 30 Mar 2012 03:30:00 -0000

On Thu, Mar 29, 2012 at 5:59 PM, Gregory Maxwell <gmaxwell@juniper.net>wrote;wrote:

> 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.
>
>
I guess what you are saying (and I believe everybody on this list agree) is
that SDES-SRTP in combination with JavaScript signaling negotiation does
not and cannot provide any meaningful security above preventing simple
network sniffing.
_____________
Roman Shpount