Re: [rtcweb] Encryption mandate

Paul Kyzivat <> Thu, 08 September 2011 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C51421F889A for <>; Thu, 8 Sep 2011 09:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6wLTFgsatdWJ for <>; Thu, 8 Sep 2011 09:17:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B2CF21F87FA for <>; Thu, 8 Sep 2011 09:17:15 -0700 (PDT)
Received: from ([]) by with comcast id WGJG1h00316LCl057GK8ts; Thu, 08 Sep 2011 16:19:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id WGK61h00t0tdiYw3SGK7ul; Thu, 08 Sep 2011 16:19:08 +0000
Message-ID: <>
Date: Thu, 08 Sep 2011 12:19:41 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Michael Procter <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 08 Sep 2011 16:17:16 -0000

On 9/8/11 5:33 AM, Michael Procter wrote:
> Paul, Olle,
> Both of you correctly point out that determining when a session is
> secure is a very hard problem - one that is nigh-on impossible except
> for certain restricted scenarios.  But I think we may have missed the
> change of emphasis in Chris' proposed UI change.  Instead of marking a
> session as secure (which is hard to determine), he is suggesting
> marking it as insecure (which is easier!).
> If the signalling and media entering and leaving the browser are not
> secured by an appropriate mechanism, then the session should be marked
> as 'insecure'.  If they are secured, then Chris' proposal would have
> no indication on the browser, which intuitively seems to match what we
> know about the session - secure to the server but 'who knows' after
> that.  Whether that is good enough for you will depend on whether you
> trust the service you are using.

I agree that this might provide some utility that isn't otherwise 
achievable. However, trusting the service remains an issue. Big brother 
will probably ensure that most of them have back doors.


> Michael
> On 8 September 2011 06:48, Olle E. Johansson<>  wrote:
>> 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
>> On 9/7/11 4:20 PM, Christopher Blizzard wrote:
>> 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