Re: [rtcweb] Encryption mandate

"Olle E. Johansson" <oej@edvina.net> Thu, 08 September 2011 05:46 UTC

Return-Path: <oej@edvina.net>
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 EB28921F8797 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 22:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001]
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 EQNp956YOasZ for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 22:46:10 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0021F856B for <rtcweb@ietf.org>; Wed, 7 Sep 2011 22:46:09 -0700 (PDT)
Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 69F46754BCE4; Thu, 8 Sep 2011 05:47:59 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BB515AC-D4BF-4BDD-8572-45BEBCD9D706"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <4E6808D5.7090709@alum.mit.edu>
Date: Thu, 8 Sep 2011 07:48:01 +0200
Message-Id: <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net>
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> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1244.3)
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: Thu, 08 Sep 2011 05:46:11 -0000

8 sep 2011 kl. 02:14 skrev Paul Kyzivat:

> Chris,
> 
> I agree with you that the UI indication of security is important.
> But its also *hard* for this application, for a variety of reasons:
> 
> - While it may be easy for the browser to know if the media stream
>  is itself secured, its hard (impossible) to know that its secured
>  to its ultimate end point. That is the problem with intermediaries.
> 
> - it may turn out that not all the streams in the "call" have the
>  same degree of security.
> 
> Of course this can all be dealt with via proper definition of what the UI indication means, and doesn't mean. But doing that will just render it meaningless to many users. To be widely understood, the indication will need to be simple, and closely aligned with what people "expect".
> 
> Consider a stream that is secured to a PSTN gateway, and then travels over the PSTN to somebody's phone. Should that be considered a "secure" call? Or an "insecure" call? Or somewhere between those?
> 
> Its going to be hard work to figure out what can both be reliably reported to users and also be understandable and meaningful to users.
> 
Agree. I see your way of thinking as an argument to make all sessions confidential, encrypted by default. We can't reliable define a "secure call" and separate insecure sessions from secure sessions. Which mean that a UI indication won't mean anything. We can just make sure that the first hop is protected, the rest is up to the application that operates the media session.

/O
> 	Thanks,
> 	Paul
> 
> 
> On 9/7/11 4:20 PM, Christopher Blizzard wrote:
>> 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
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden