Re: [rtcweb] Encryption mandate

Dzonatas Sol <> Wed, 07 September 2011 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB31421F8CE2 for <>; Wed, 7 Sep 2011 12:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.066
X-Spam-Status: No, score=-4.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AiRHKs9zSky8 for <>; Wed, 7 Sep 2011 12:59:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B59E221F8CE0 for <>; Wed, 7 Sep 2011 12:59:51 -0700 (PDT)
Received: by yxj20 with SMTP id 20so19354yxj.31 for <>; Wed, 07 Sep 2011 13:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xxjc8RCcPBcPH2ZVf1O3MSBSFqtb+WAoWFmnx8DVxKk=; b=BRHZDGrVzt81w7PL/sC41gnrtHPQEz/v/LOC21aTUxLQ3vtogIZv1nZoKteQdLTtDs f2GUdccesbA3fPByYskVmQWybNO8HOj1j96CvGqvFXVLRVDJkBySsQ1sBK9rcXPc0msA iXr2FwxuEKT+9Ba575+eHdhpr/VnG1ML31Nao=
Received: by with SMTP id l4mr2631097icn.221.1315425701566; Wed, 07 Sep 2011 13:01:41 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id el2sm1155333ibb.10.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:01:40 -0700 (PDT)
Message-ID: <>
Date: Wed, 07 Sep 2011 13:03:34 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <> <><> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Encryption mandate
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: Wed, 07 Sep 2011 19:59:52 -0000

On 09/07/2011 12:20 PM, Randell Jesup wrote:
> Splitting the two topics....
> On 9/7/2011 3:07 AM, Olle E. Johansson wrote:
>> To fearlessly  jump into another can of worms, I still think we 
>> should have confidentiality - SRTP - by default. We know that these 
>> applications will run on a myriad of devices on a myriad of networks 
>> and it will not work to let users have to decided whether or not they 
>> want confidentiality. If Skype did not have confidentiality by 
>> default, there would be articles every summer and xmas in the evening 
>> taboloids about how easy it is to listen in to your neighbours calls 
>> and that would have hurted Skype badly.
> There is a strong argument for this.  The strongest argument for the 
> other side is  you don't need a media gateway to talk to non-WebRTC 
> endpoints, just a signalling gateway.  This means less delay 
> potentially (especially if the application provider has gateways only 
> in one geographic location) and less expense for the server provider 
> for a pretty common usecase (gateway to PSTN).  The delay could be a 
> significant issue.
> It was also brought up that some usecases for internal PBX/business 
> use would not need/prefer forced encryption.  As mentioned at the 
> meeting, encrypting to the media gateway only gets you a modicum of 
> privacy (though it might protect you from the "neighbor's wifi 
> capture" case).
> You could make forced-encryption the default, and allow the 
> application control over whether to allow it is turned off for 
> specific cases, like a PSTN call, or under the server's control.  
> Signalling is secure, so it could even use a direct optional downgrade 
> from SAVP* to AVP* (i.e. similar to the best-effort-strp draft)
> It's a tough call - guaranteed (local) security is nice, but I worry 
> about those relay cases like taiwan->USA media gateway->taiwan.  Not a 
> huge deal on signaling/call-setup, but media...

Flip-side: contracts already force encryption, and that is one reason 
why people do not want contracts; they want open wi-fi so neighbors have 
no walls across net points. Developers fear those pitchforks when they 
could have used security other than contract-stated default. That messes 
up everybody elses units not on those contacts, so you are back to ICE 
or force each person back to single connection to trunk internet lines 
and stateful-hubs (i.e. rtcweb on the base phone, not the hand-set, with 
audio-whitespaces or the base phone unit acts as DSL-filter end-point.).

--- ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant