Re: [rtcweb] Encryption mandate

Christopher Blizzard <blizzard@mozilla.com> Wed, 07 September 2011 20:18 UTC

Return-Path: <blizzard@mozilla.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 540E221F8D5B for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 13:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4hGz4zjSYYD6 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 13:18:15 -0700 (PDT)
Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA221F8D5A for <rtcweb@ietf.org>; Wed, 7 Sep 2011 13:18:15 -0700 (PDT)
Received: from [10.250.4.144] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id 080F5AE6465A; Wed, 7 Sep 2011 13:20:05 -0700 (PDT)
Message-ID: <4E67D1F4.10002@mozilla.com>
Date: Wed, 07 Sep 2011 13:20:04 -0700
From: Christopher Blizzard <blizzard@mozilla.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Randell Jesup <randell-ietf@jesup.org>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org>
In-Reply-To: <4E67C3F7.7020304@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Encryption mandate
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, 07 Sep 2011 20:18:16 -0000

On 9/7/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...
>
>

I want secure-by-default, maybe even secure-only.

Even if it's not secure-only there's also an important UI consideration 
depending how we end up doing that in browsers.  In the past we've made 
the secure mode special (the lock icon in the early days, now the 
green/blue bar) but I think that we should be making the insecure mode 
special.  That is, always mark a connection as very clearly unencrypted 
via UI affordances.  Just like banks "wanting to know how to get the 
lock icon" we should be making call sites "wanting to know how to get 
rid of that huge ugly warning that makes us look bad."

Once again, I would much prefer secure-only, but I'll take 
secure-by-default across browsers if I can get it.

--Chris