Re: [rtcweb] Support of SDES in WebRTC

Roman Shpount <> Fri, 30 March 2012 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C45DA21F86BA for <>; Thu, 29 Mar 2012 20:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.836
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gxgS-Va5nC4s for <>; Thu, 29 Mar 2012 20:30:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F1CB121F86B6 for <>; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1051489pbb.31 for <>; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id ue6mr5434577pbc.14.1333078199709; Thu, 29 Mar 2012 20:29:59 -0700 (PDT)
Received: from ( []) by with ESMTPS id i1sm6358918pbj.70.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1051459pbb.31 for <>; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id in3mr5481157pbc.118.1333078198064; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
Received: by with HTTP; Thu, 29 Mar 2012 20:29:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 29 Mar 2012 23:29:58 -0400
Message-ID: <>
From: Roman Shpount <>
To: Gregory Maxwell <>
X-Gm-Message-State: ALoCoQmKRc/7UQtfJuUZ7VvKUNUZ6wuWvykPD6l+VD+IDnfURCldX16pEEC/ZOps7VZjqamfPOPc
Content-Type: multipart/alternative; boundary="e89a8ff1c65a7415ad04bc6d7467"
Cc: "<>" <>
Subject: Re: [rtcweb] Support of SDES in WebRTC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Mar 2012 03:30:00 -0000

On Thu, Mar 29, 2012 at 5:59 PM, Gregory Maxwell <>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