Re: [rtcweb] SRTP and "marketing"
"Richard L. Barnes" <rbarnes@bbn.com> Wed, 28 March 2012 10:43 UTC
Return-Path: <rbarnes@bbn.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 6E03821F8A19 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 03:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.538
X-Spam-Level:
X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 iWrlYPjpDUu3 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 03:43:35 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 684E621F8A14 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 03:43:34 -0700 (PDT)
Received: from [128.89.255.12] (port=58632 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1SCqLX-000Gh1-GT; Wed, 28 Mar 2012 06:43:19 -0400
Message-ID: <4F72EB53.5000409@bbn.com>
Date: Wed, 28 Mar 2012 12:43:31 +0200
From: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no>
In-Reply-To: <4F72E453.7070204@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
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 10:43:36 -0000
>> 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. > If there are, we need to close them before we ship the specs. > Given reasonable practices (such as using only HTTPS for loading the > pages and JS libraries), if we can't deliver security (against known > attacks), we shouldn't ship the spec. I agree that we should lock things down to the extent we can, and I think we will be able to do pretty well, using things such as you note. But at base, without authentication, you cannot prevent MitM if someone is in the right place in the network. You can just constrain the set of places from which an MitM can be launched. >> So ISTM the "marketing" argument carries with it some serious risks as >> well as some small possible benefit. > Only if we don't deliver. Except that "deliver" in this case entails a global authentication/identity infrastructure. And it seems unlikely that we'll deliver that in the short run. --Richard
- [rtcweb] SRTP and "marketing" Richard L. Barnes
- Re: [rtcweb] SRTP and "marketing" Harald Alvestrand
- Re: [rtcweb] SRTP and "marketing" Richard L. Barnes
- Re: [rtcweb] SRTP and "marketing" Mahalingam Mani
- [rtcweb] Identity and authorities (Re: SRTP and "… Harald Alvestrand
- Re: [rtcweb] SRTP and "marketing" Basil Mohamed Gohar
- Re: [rtcweb] SRTP and "marketing" Dan Wing
- Re: [rtcweb] SRTP and "marketing" Hadriel Kaplan
- Re: [rtcweb] SRTP and "marketing" Hadriel Kaplan
- Re: [rtcweb] SRTP and "marketing" Jim Barnett
- Re: [rtcweb] SRTP and "marketing" Randell Jesup
- Re: [rtcweb] SRTP and "marketing" Timothy B. Terriberry
- Re: [rtcweb] SRTP and "marketing" Roman Shpount
- Re: [rtcweb] SRTP and "marketing" Fabio Pietrosanti (naif)
- Re: [rtcweb] SRTP and "marketing" Fabio Pietrosanti (naif)
- Re: [rtcweb] SRTP and "marketing" Fabio Pietrosanti (naif)
- Re: [rtcweb] SRTP and "marketing" Roman Shpount
- Re: [rtcweb] SRTP and "marketing" Hadriel Kaplan
- Re: [rtcweb] SRTP and "marketing" Dan Wing
- Re: [rtcweb] SRTP and "marketing" Randell Jesup
- Re: [rtcweb] SRTP and "marketing" Timothy B. Terriberry
- Re: [rtcweb] SRTP and "marketing" Hadriel Kaplan
- Re: [rtcweb] SRTP and "marketing" Gregory Maxwell
- Re: [rtcweb] SRTP and "marketing" Oscar Ohlsson