[rtcweb] Call Security (was Re: Let's define the purpose of WebRTC)

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 15 November 2011 01:14 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7F05911E8189 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 17:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ebb-xJy0cQv2 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 17:14:07 -0800 (PST)
Received: from mx.skype.net (mx.skype.net []) by ietfa.amsl.com (Postfix) with ESMTP id 38C1011E8136 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 17:14:07 -0800 (PST)
Received: from mx.skype.net (localhost []) by mx.skype.net (Postfix) with ESMTP id 83DFF7FE; Tue, 15 Nov 2011 02:14:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=9AWP62SNpprFr6LC0XWtze7FnC8=; b=SwT6LddGc vObwCU5HuxGGP1LlObLf8OKRxdEjAunRsU9dqy2P/kVCc0K8uxvWfl7y0OWabxRC HClxe+blBaWys6oOblS9rFiXZO6bdocorFG0G7vmbccNvIZBU4Qh4vefyGUzHMai PvFjA2kq0mDCqj17L0FX5Z/evG7NjxZppw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=rHnRob/azkUd+MFrPjrMe1u7gvd5Gr9Sdj7lVKAZd8SjxT6r sr7aUkK1bSks+W4+JZkZ6jMy7+IwiiNt+IWpq5t7LhAyntzRG1kzLfM+vI9YC32M YGyEMpzFCmfk1NE/rIOgZomsOAoHvv2wt9Nf6/HSuOJRR2whejQvxcye6tA=
Received: from zimbra.skype.net (zimbra.skype.net []) by mx.skype.net (Postfix) with ESMTP id 820FB7EB; Tue, 15 Nov 2011 02:14:06 +0100 (CET)
Received: from localhost (localhost []) by zimbra.skype.net (Postfix) with ESMTP id 577F13506F05; Tue, 15 Nov 2011 02:14:06 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([]) by localhost (zimbra.skype.net []) (amavisd-new, port 10024) with ESMTP id J8QfJ8vYJs0O; Tue, 15 Nov 2011 02:14:04 +0100 (CET)
Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org []) by zimbra.skype.net (Postfix) with ESMTPSA id A35B53506E8F; Tue, 15 Nov 2011 02:14:02 +0100 (CET)
Message-ID: <4EC1BCD9.8000408@skype.net>
Date: Tue, 15 Nov 2011 09:14:01 +0800
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxt=k_Mon_GMs1w-bGMgpk12h6ZQ=FkoRVsTp4271iMSLA@mail.gmail.com> <CABcZeBNMTgwH-R_jd-AiEJ8tELTeFMNm-bAJohRg2RxD5e+kZQ@mail.gmail.com> <CAD6AjGRBmrAqB3CEWxtaXnryPA5App13S2jJPAt+7HwWZsQFzA@mail.gmail.com> <CABcZeBNtoizuRymVMxF4CdiLu1Nju63C0xkWJHjoarpxeLXjyA@mail.gmail.com> <CALiegfk=oJJ20GhKQBKA7aspHhUyQ-s+DR-qSi4XV455Nj718w@mail.gmail.com> <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <CAD5OKxvN5YY13UGQeZGL-znzw9UR_2oXS_RV8FQx1MW8hqWzqg@mail.gmail.com> <4EC1B58E.7060206@skype.net> <CAD5OKxuCAPZc_zm5uZEHfJgPiadoS-UPH1fSFW0dj9RNAoKUcg@mail.gmail.com>
In-Reply-To: <CAD5OKxuCAPZc_zm5uZEHfJgPiadoS-UPH1fSFW0dj9RNAoKUcg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000107020300000802090000"
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: [rtcweb] Call Security (was Re: Let's define the purpose of WebRTC)
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: Tue, 15 Nov 2011 01:14:08 -0000

On 11/15/11 9:02 AM, Roman Shpount wrote:
> On Mon, Nov 14, 2011 at 7:42 PM, Matthew Kaufman 
> <matthew.kaufman@skype.net <mailto:matthew.kaufman@skype.net>> wrote:
>     Do you want *your* browser to be able to switch to plain RTP for
>     the call you're making from a place with an unsecured wi-fi
>     network (as essentially all are at this point, given the ease of
>     cracking the typical schemes used for wireless security these days) ?
>     I don't. Even though I do agree that there might be external
>     reasons why service providers might want the browser to have that
>     ability.
> I guess you are missing the point on two accounts:

Perhaps. They're unrelated, so I'll answer separately.
> First of call, in most of the cases I (as well as possibly most of the 
> people) do not care. If I am sitting on the public WiFi in a coffee 
> shop, I do not care, because there are hundreds of people around who 
> already hear what I am saying.
But they're not able to record what you're saying from a close-up 
microphone. Nor can they record you from a car sitting outside the 
coffee shop. Nor can they record what the far end is saying. Nor can 
they replace what you're saying with alternative audio.

All of which *are* possible when plain RTP is sent over public WiFi.

> Almost all traditional phone conversations provided no privacy (just 
> ask your friendly phone technician which a handset in the basement), 
> and most of people did not care.

Just because phone tapping is relatively easy doesn't mean we shouldn't 
be improving the state of the art here.

> Cell phones are not as private as you would think (I know of examples 
> when entire countries turned the encryption off for a few months) and 
> users did not care. Encryption is good, but not as important as you 
> are making it to be.

To you.

> Second, it is an application developers decision if he wants to 
> provide secure communications. If he does not intend to (all 
> conversations are recorded and posted on the web as a voice blog for 
> example), there is no point of forcing this encryption.

Maybe. Even if the conversations are recorded and posted, there might be 
cases where you don't want alternative audio being substituted. (For 

> No matter what we do on the browser side, the app will never be 
> secure, if it is not intended to be so. In this case all this 
> encryption is a wasted effort. It is not a web browser or a user 
> decision if communications with a particular app should be secure. 
> User should be able to see that the certain application takes no 
> effort in securing the communications and decide if they would use 
> this application based on this. The simplest and probably best 
> understood model by web users is, if an application is delivered over 
> HTTPS from a known provider, it should be secure. If it is delivered 
> over HTTP, it provides no guarantees over its security and should be 
> used this at your own risk.

You really don't want to ever provide access to your camera and 
microphone to an application delivered over HTTP, because once it is 
delivered over HTTP you don't know that the application hasn't been 
replaced with something that sends your camera and microphone to 
somewhere other than what you had intended. And you *definitely* don't 
want to press the "remember my choice" checkbox for applications 
delivered over HTTP.

In short, I would strongly suggest that applications delivered over HTTP 
*never* be able to access your camera and microphone. (Noting that in 
most cultures, knowing what a user is looking at or typing isn't nearly 
as sensitive as listening in or seeing what the user happens to be 
wearing (or not wearing)).

Matthew Kaufman