[secdir] WebRTC

Hank Nussbacher <hank@efes.iucc.ac.il> Sun, 08 April 2012 09:11 UTC

Return-Path: <hank@efes.iucc.ac.il>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1346A21F84A1 for <secdir@ietfa.amsl.com>; Sun, 8 Apr 2012 02:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.587
X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACED_SUBJECT_WORD3=2.412]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nZkvgQceT7gu for <secdir@ietfa.amsl.com>; Sun, 8 Apr 2012 02:11:33 -0700 (PDT)
Received: from efes.iucc.ac.il (efes.iucc.ac.il []) by ietfa.amsl.com (Postfix) with ESMTP id 09BBB21F84AF for <secdir@ietf.org>; Sun, 8 Apr 2012 02:11:32 -0700 (PDT)
Received: from hank-lenovo.efes.iucc.ac.il (adsl-v01-32a5522ebb.tau.ac.il []) by efes.iucc.ac.il (Postfix) with ESMTP id EA341318074; Sun, 8 Apr 2012 12:11:26 +0300 (IDT)
Message-Id: <>
X-Sender: hank@efes.iucc.ac.il
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 08 Apr 2012 12:11:22 +0300
To: stephen.farrell@cs.tcd.ie, turners@ieca.com, secdir@ietf.org
From: Hank Nussbacher <hank@efes.iucc.ac.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-Mailman-Approved-At: Sun, 08 Apr 2012 05:34:51 -0700
Subject: [secdir] WebRTC
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2012 09:14:53 -0000

Dear Security Area people,

Quick intro:

WebRTC http://www.webrtc.org/ is a free, open project that enables web 
browsers with Real-Time Communications (RTC) capabilities via simple 
Javascript APIs.   It is supported by Google, Mozilla and Opera.  One can 
test it already in Chrome. Basically, it is meant to be a Skype replacement 
technology (no app to download - all built-in to the browser).  But there 
are many other ideas that can be used here with this technology.

Now we get to the security part.  As stated here: 
one has to specifically enable "--enable-media-stream" in order to get it 
to work. That is now, but the future plan is to have this "on" by default 
in FF and Chrome by the end of 2012.

So what does the IETF have to say:

Security Considerations for RTC-Web
which caused:
RTCWEB Security Architecture
Section 5.2:
"Clients MAY permit the formation of data channels without any direct user 

I can just see new apps all over the place using this technology opening a 
huge can of worms for data stealing from the PC running the app that did 
NOT ask permission for the formation of a data channel without the direct 
user's permission.  This is similar in concept to ActiveX:
"This made the web "richer" but provoked objections (since such controls 
ran only on Windows) and security risks (especially given the lack of user 
intervention). Microsoft subsequently introduced security measures to make 
browsing including ActiveX safer[6] . For example:

     digital signing of installation packages (Cabinet files and executables)
     controls must explicitly declare themselves safe for scripting
     increasingly stringent default security settings
     Internet Explorer maintains a blacklist of bad controls"

Microsoft didn't envision the security issues of a "lack of user 
intervention" and it took them 3 years to add the appropriate knobs to make 
ActiveX more secure.

I am not involved in WebRTC or the IETF group - I only found out about this 
incidentally.  I raise this issue to you guys and leave it the Security 
Area to decide whether section 5 needs to be changed or not.

Hank Nussbacher