Re: [rtcweb] Support of SDES in WebRTC

Gregory Maxwell <gmaxwell@juniper.net> Thu, 29 March 2012 21:59 UTC

Return-Path: <gmaxwell@juniper.net>
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 6BD2421E8050 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 14:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 6HOrPFvrvN5D for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 14:59:20 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A59C121E802A for <rtcweb@ietf.org>; Thu, 29 Mar 2012 14:59:20 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TbNdROHEisdRJ2o4CQ1TwMuWev1oW7@postini.com; Thu, 29 Mar 2012 14:59:20 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 29 Mar 2012 14:59:03 -0700
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Oscar Ohlsson <oscar.ohlsson@ericsson.com>, =?Windows-1252?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 29 Mar 2012 14:59:03 -0700
Thread-Topic: [rtcweb] Support of SDES in WebRTC
Thread-Index: Ac0NwVWL/pAf3KWyRBuDtl/dfJ3iTAALdbdgAAFEo7Y=
Message-ID: <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>
In-Reply-To: <A1B638D2082DEA4092A268AA8BEF294D194602DB63@ESESSCMS0360.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 29 Mar 2012 21:59:21 -0000

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