Re: [rtcweb] SRTP and "marketing"

"Dan Wing" <dwing@cisco.com> Wed, 28 March 2012 16:59 UTC

Return-Path: <dwing@cisco.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 4C7D921E8258 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 09:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.443
X-Spam-Level:
X-Spam-Status: No, score=-109.443 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tEJWbFo1ZRQ7 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 09:59:28 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB721E8254 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 09:59:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2978; q=dns/txt; s=iport; t=1332953968; x=1334163568; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Ow8EY9KMSSZZZpf2tSL7kYUSXXp4XFD8XqIpT1QTzuk=; b=IRlg9gva6AevgFaZcTzSB23r7YqLb6tFxVAJbuBk7oWB+ONjr5kkCbAO BUcy7ZgE/feLl0W4VAV+VNYMenIvdl6NWAB8Erc5JxtDMeP5emyd06cBg uilOSHGfiTSJ/zC42H2X/1+R3clyutZz+3k8FzqS1QK19kOt6AK5qODuM M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAH1Cc0+rRDoI/2dsb2JhbAA8CakKj2KBB4IJAQEBBAEBAQUKARcQLQcBCgwBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxeHZwybep8fBIpvhiMEjWuWO4Fogmk
X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="37962956"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Mar 2012 16:59:28 +0000
Received: from dwingWS (sjc-vpn2-273.cisco.com [10.21.113.17]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2SGxQlZ014793; Wed, 28 Mar 2012 16:59:27 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Richard L. Barnes'" <rbarnes@bbn.com>, "'Harald Alvestrand'" <harald@alvestrand.no>
References: <4F72D6B3.40803@bbn.com> <4F72E453.7070204@alvestrand.no> <4F72EB53.5000409@bbn.com>
In-Reply-To: <4F72EB53.5000409@bbn.com>
Date: Wed, 28 Mar 2012 18:59:26 +0200
Message-ID: <0bf301cd0d04$22d53200$687f9600$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0Mz6RtUjUda4oFQsOOmqoPd72ayQANE4PQ
Content-Language: en-us
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 16:59:29 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Richard L. Barnes
> Sent: Wednesday, March 28, 2012 12:44 PM
> To: Harald Alvestrand
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] SRTP and "marketing"
> 
> >> 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.

We do need a foundation upon which an authentication/identity 
infrastructure can be built.  We know we need one.

That foundation is DTLS-SRTP, and not Security Descriptions.

-d



> 
> --Richard
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb