Re: [rtcweb] SRTP and "marketing"

Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org> Wed, 28 March 2012 14:51 UTC

Return-Path: <abu_hurayrah@hidayahonline.org>
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 42CEF21E828B for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 07:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level:
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 6afr0BXOB0Cl for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 07:51:34 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 76C2321E8287 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 07:51:34 -0700 (PDT)
Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 942086524A1 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 10:51:33 -0400 (EDT)
Message-ID: <4F732562.6010902@hidayahonline.org>
Date: Wed, 28 Mar 2012 10:51:14 -0400
From: Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F72D6B3.40803@bbn.com>
In-Reply-To: <4F72D6B3.40803@bbn.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=5AF4B362
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] SRTP and "marketing"
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, 28 Mar 2012 14:51:35 -0000

On 03/28/2012 05:15 AM, Richard L. Barnes wrote:
> I didn't make it to the mic at the meeting today, but I wanted to
> express one concern about the possibility of making RTCWEB SRTP-only.
>
> Hadriel mentioned the "marketing value" of having always-on
> encryption, this idea that only supporting SRTP will make RTCWEB look
> like something secure and trustworthy.  I'm concerned that this might
> not be the case, and in fact that being SRTP-only might effectively be
> an over-promise, in light of the fact the absence of universal
> authentication.
>
> Hadriel noted that the competitors to this technology are Skype and
> Flash, and it's worth considering the security situation with these
> technologies, because they kind of bracket RTCWEB.  With Skype
> (assuming they've designed it properly), there is actually a universal
> authentication, under a single authority.  So you really do know that
> you're talking to whatever Skype ID you intend to, and nobody else.
> With Flash, well, does anyone expect it to be secure anyway?
>
> What I'm concerned about in the RTCWEB context is that without a
> universal authentication/identity infrastructure, we will end up
> *promising* a secure call, but not *delivering* it.  I haven't done
> the analysis, but it does not seem implausible to me that
> FireSheep-like vulnerabilities are lurking here.
>
> So ISTM the "marketing" argument carries with it some serious risks as
> well as some small possible benefit.
>
> --Richard
If I'm totally missing the point (not having attended the event
mentioned), please disregard what I have to say.

I think that there is a value to having an encrypted connection, even if
it does not combine with it authentication from both ends, as this
would, at the very least, prevent snooping of the communications between
the two end points.  This would be the equivalent of using a self-signed
certificate for HTTPS, without the drama of the certificate warnings we
get in browsers.

What I mean is, we can make the higher degree of security be one that
combines authentication with encryption, but always-on encryption can be
the default, and this is what I meant by saying it still has value.  At
least a 3rd-party would not be able to spy on communications between two
people and the connection has a minimum degree of privacy to it. 
Combined with a trusted method of establishing authentication, whether
via a central authority (e.g., current CA's) or allowing users to
exchanged keys via other channels (e.g., PGP chain of trust style), then
a fully trustworthy and private method of communications can be established.

I hope the two degrees I am pointing out are clear.