Re: [rtcweb] Consensus call regarding media security

Roman Shpount <> Thu, 29 March 2012 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E247321E8051 for <>; Wed, 28 Mar 2012 22:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.829
X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.147, 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 SOKgRZq8gmPa for <>; Wed, 28 Mar 2012 22:56:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C61921E8015 for <>; Wed, 28 Mar 2012 22:56:26 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2961596pbb.31 for <>; Wed, 28 Mar 2012 22:56:26 -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:content-type:x-gm-message-state; bh=qYRTst560ZJjlODwcEs2/B+7ZUNBY5j7b6qFnp0EoOk=; b=Pr1yhBdt3rT+gv9fWerDZL7LZFE0lIRL2TSEvNZ1uCr4OGRtnwA5dj6GUQ4mB4PlpD hlZpKSewt2vNmPObehuX0i0q+g+vo7IPETpJ81NxIcxZorpYax+y2caBSobF17EodYBQ Rd+pxxKt+dpD/bY5QhXi0ckjeHNVICC2Z9LfSeYVXIU3rHSpR6uxiHdAmGQlv4OZdsCE fU3kB4nDmPimzYCTiBPjLKEmuAhPr/XvoL7knUhB7CZIHcP6JeQZxLg9DG9HkDuxlvug 0z/FWIXsAfVS+/nKy+zs19fBJwb12S3ZWzwjrZMUcK03/LBKgHzix4bdmSy0aEvMi+Zv ieEA==
Received: by with SMTP id pq10mr2911224pbb.24.1333000585819; Wed, 28 Mar 2012 22:56:25 -0700 (PDT)
Received: from ( []) by with ESMTPS id z1sm4270382pbc.38.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 22:56:24 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2961538pbb.31 for <>; Wed, 28 Mar 2012 22:56:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id pp8mr2831960pbb.13.1333000583049; Wed, 28 Mar 2012 22:56:23 -0700 (PDT)
Received: by with HTTP; Wed, 28 Mar 2012 22:56:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 29 Mar 2012 01:56:22 -0400
Message-ID: <>
From: Roman Shpount <>
To: Basil Mohamed Gohar <>
Content-Type: multipart/alternative; boundary=047d7b10d17b3cf37504bc5b6222
X-Gm-Message-State: ALoCoQl28lqF1qMOFNijmq7ayVIECg4dv2au3zpTw2lMtMI1vqVsumer/7je/CiA0rGxrY0Ekr59
Subject: Re: [rtcweb] Consensus call regarding media security
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: Thu, 29 Mar 2012 05:56:27 -0000

On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar <> wrote:

> The scope of WebRTC is broad enough to consider that we need to think
> about what's best going forward with regards to its implementation.
> Security by default is one of the best practices in general, the support
> from the browser community and others that are behind it will definitely
> ensure that adoption is widespread enough to make it easy enough to
> integrate into existing systems, as free software solutions will become
> available shortly after the standard emerges.
I would actually challenge the assumption that free software will emerge.
SRTP with SDES was released 8 years ago. The only open source library that
supported it until recently was libsrtp, which is a broken unusable peace
of code spaghetti (GPF crashes, two different replay DBs which do the same
thing, random number generator that stops working after generating few
thousand keys) that supports 2/3 of the protocol (no F8 support). Majority
of open source (and a large number of closed source) clients use this
library, but do not see any of those issues since very few real SRTP calls
are actually placed. DTLS-SRTP is two years old. Support for it was just
added to GNU TLS (unusable by many due to GNU license) and to OpenSSL
(using above mentioned libsrtp). There is little or no experience with
DTLS-SRTP interop. All of these things are not trivial.

My point is, if we require support for encryption implementation in the
standard and if 4 or 5 browser vendors will cooperate, we will get vast
majority of WebRTC clients security enabled. If everything surrounding
WebRTC will not use encryption, it is not a big loss since, in most cases,
it is not doing now anyway.
Roman Shpount