Re: [rtcweb] Consensus call regarding media security

Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org> Wed, 28 March 2012 21:08 UTC

Return-Path: <abu_hurayrah@hidayahonline.org>
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 9321E21E8040 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 14:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
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 qR+2QqgrFLvw for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 14:08:13 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E513821E800E for <rtcweb@ietf.org>; Wed, 28 Mar 2012 14:08:12 -0700 (PDT)
Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id D275865256F for <rtcweb@ietf.org>; Wed, 28 Mar 2012 17:08:08 -0400 (EDT)
Message-ID: <4F737DB3.5020804@hidayahonline.org>
Date: Wed, 28 Mar 2012 17:08:03 -0400
From: Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F732531.2030208@ericsson.com> <CAD5OKxs6NHha2egNSTumEaHYJ0bB6qu_nfshmBM6dntx2n49HQ@mail.gmail.com> <CALiegfn4MZYb-qCnM62T7w4EgWqrC5baN+pAYBZF84kEA7Ko6A@mail.gmail.com> <CAD5OKxtDED1vSFrw4V9TKkUzdSSXNg+S_WBrxmnFo21hjJvqMA@mail.gmail.com>
In-Reply-To: <CAD5OKxtDED1vSFrw4V9TKkUzdSSXNg+S_WBrxmnFo21hjJvqMA@mail.gmail.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=5AF4B362
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Wed, 28 Mar 2012 21:08:13 -0000

On 03/28/2012 04:41 PM, Roman Shpount wrote:
> My main objection is that if an application developer does not take
> care to develop a secure application, nothing you can do on the
> standard side will make it a secure application. If I am building a
> public voice blog that records a voice message that anybody can listen
> to on the web site security is not needed. My assumption is that a
> fair number of applications would be like this. So for such
> applications this is an unnecessary feature.
>
> WebRTC will not exist in vacuum. It will communicate with other
> systems. It is not limited to old SIP devices. It can be something new
> like server side speech recognition that is integrated with web
> application. For such application extra code and interop requirements
> to support security will represent a real and significant cost. Any
> requirement, unless absolutely necessary will create barriers to entry
> for new applications. I would like to avoid as many of those as
> possible. 
> _____________
> Roman Shpount
Roman,

You make a lot of good points.  However, the inverse is true as well -
namely, that is if encryption is not mandated, most implementations will
likely leave it out, and adoption of secured communications would be
stifled even longer.  I cannot speak about the implementation
difficulties, but I can speak from the user side that most people will
remain ignorant of the underlying technology and not know enough to
demand nor enable a feature if it is optional to implement and/or use.

As WebRTC is a new standard, requiring encryption will ensure that, at
least going forward, the important concept of encryption is widely
adopted correctly from the beginning.  Tacking it on later, no matter
how much it is emphasized, will be difficult or impossible.

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.