Re: [rtcweb] Consensus call regarding media security

Justin Uberti <juberti@google.com> Thu, 29 March 2012 14:00 UTC

Return-Path: <juberti@google.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 3398921E801B for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 07:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.786
X-Spam-Level:
X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 mcRJezw2qrzz for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 07:00:33 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E02AF21E801A for <rtcweb@ietf.org>; Thu, 29 Mar 2012 07:00:32 -0700 (PDT)
Received: by qaea16 with SMTP id a16so96808qae.10 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 07:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=135gqUMnI5lIkow1z7WQDsRpAjQ5f59ZBzoxtkORFS4=; b=kHPCO0y/aFjGM+iWHtVvYSwuA3mf4K3Bc9uZz2N8FJF9F7J0AdXzbRDfdmjPzwSMCL TSsqBCxfZQSrJXQ2ImuDseH228VHLhkaLRcZNT2ANgATe7VRmFyM/yP343YaO2+3val3 UJRY7Zu36acLGPHKNuiGeKfw6Brwg0bhYqu8ky380GXzUF2l88/wXQXVM+KWIb0OBeEP oo6lhoAo5ahWjVlgn2kZJGjl2GyKgNJqYRkoFLFlTZVrUyS/4m6YWcYLmnZHh+SxQjHw NoX2gxHSSAbwC/ToF8flu/zp7oiz9CGG8UVPHhPoUzurlXz+z5WLH+gCQx5OkVQ14iiE zYeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=135gqUMnI5lIkow1z7WQDsRpAjQ5f59ZBzoxtkORFS4=; b=MK5YMupw2oYwwnhyHObOuv9+wa3UiKpFqNtJ3P7gL/xxHDD0UL3GQpWggexSoBk56R y8sV+GT2xJu3uVSIcpgAGY3s9YIQOn3Id7g7rMgMZE2RypDB0VScU1Ppxwjm8GEH6JBL hnWl2tlGE5DfufIEWcBfVCbKl5Z1DUH/LkOTi4znEqKXf13g5g7Y58BbIRUVKa1lYy+7 IhUMbzoeYB0AZXziRoRIEpZRlM7TjObB6Q9/0m9+E7wZ69saBmJrl/ue8JHxn8XPZkEl EvXfB8DSeNzhUJrzGTr8NjHuL7AF0hG1msUHs04n9ZCK/5K8xVSvSuTIHShrLnvmPbpT whjg==
Received: by 10.224.193.69 with SMTP id dt5mr150162qab.75.1333029629636; Thu, 29 Mar 2012 07:00:29 -0700 (PDT)
Received: by 10.224.193.69 with SMTP id dt5mr149944qab.75.1333029627498; Thu, 29 Mar 2012 07:00:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.161.134 with HTTP; Thu, 29 Mar 2012 07:00:07 -0700 (PDT)
In-Reply-To: <CAD5OKxuJq7x-_QTK49ZEgeBhMLhYQimPcs3g-BDM6vYWdH5Lng@mail.gmail.com>
References: <4F732531.2030208@ericsson.com> <CAD5OKxs6NHha2egNSTumEaHYJ0bB6qu_nfshmBM6dntx2n49HQ@mail.gmail.com> <CALiegfn4MZYb-qCnM62T7w4EgWqrC5baN+pAYBZF84kEA7Ko6A@mail.gmail.com> <CAD5OKxtDED1vSFrw4V9TKkUzdSSXNg+S_WBrxmnFo21hjJvqMA@mail.gmail.com> <4F737DB3.5020804@hidayahonline.org> <CAD5OKxuJq7x-_QTK49ZEgeBhMLhYQimPcs3g-BDM6vYWdH5Lng@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 29 Mar 2012 10:00:07 -0400
Message-ID: <CAOJ7v-0ePiqkrswGbvLZTrZCPFLGxy6KCg79kiMRtLGR9PqeOg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlF7FPBi4pI25QQEFAaZwNLVUelfGyCqRRft01cg6bIa4SZ9u6DMROgqqqRgCRWPUev1OQcnmD0SF3lRa/tIXNQ/phvwrOPogIHYD3urf2BaUKlWer72PfdMZFZmaw0XaoZIRLC
Content-Type: multipart/alternative; boundary=20cf300515066c0fdd04bc6225b8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call regarding media security
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 14:00:34 -0000

On Thu, Mar 29, 2012 at 1:56 AM, Roman Shpount <roman@telurix.com> wrote:

>
> On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar <
> abu_hurayrah@hidayahonline.org> 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.
>
>
This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over
the billions of minutes of call time to date, we haven't seen any crash
bugs that could be blamed on libsrtp. And we track this stuff pretty
closely.



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