Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Dan Wing <dwing@cisco.com> Fri, 26 April 2013 00:28 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 A457921F8EE6 for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 17:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.3
X-Spam-Level:
X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 KkcwPrkfrwCE for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 17:28:37 -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 AB2C521F8E7A for <rtcweb@ietf.org>; Thu, 25 Apr 2013 17:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3464; q=dns/txt; s=iport; t=1366936117; x=1368145717; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0PKNqJNk3zbeB+7f1eNxeCuKsqTvxvO4VnTpqELj9hU=; b=Hf7j2mXay/HKPMXeYthZEAQ055FbAJ05eVwe/K1W23YxuGk0xVinIGEl M2h6+6iuONq686rVJwXYFw61b+7g0BVu9f84wnovuYFrjC6TgVm7xU0Ou wfN2Pqs0KlKOl3nUxhpG+bW/1ep5kSDkctGsrbUti6/8H4vgKd1UKWQS0 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAI7JeVGrRDoI/2dsb2JhbABICYMGNgG+MIEFFnSCHwEBAQMBAQEBNy4GCwULCxguIQYwBhOIAgMJBQ21cQ2ISQSMX4EbgQgzB4JtYQOJEYwngWSGD4V0hR+DLhw
X-IronPort-AV: E=Sophos;i="4.87,553,1363132800"; d="scan'208";a="79569664"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2013 00:28:36 +0000
Received: from [10.32.240.196] ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3Q0SZot013325; Fri, 26 Apr 2013 00:28:35 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CABkgnnVky++ZF1uaM8p4xtzvDQH7HMCaL8N2ZV3dZDYnv-NvzQ@mail.gmail.com>
Date: Thu, 25 Apr 2013 17:28:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCF6B414-4D4D-401A-92C1-6763405992E8@cisco.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <CABkgnnVky++ZF1uaM8p4xtzvDQH7HMCaL8N2ZV3dZDYnv-NvzQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
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: Fri, 26 Apr 2013 00:28:38 -0000

On Apr 25, 2013, at 4:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> The case for SDES has thus far been summarized as (borrowing Adam's words):
> 
> (1) Those required for interop with legacy devices, and
> (2) those which we are prohibited by RFC 2804 from considering.
> 
> Reason (1) is a fairly big deal.  There are other reasons:
> 
> Performance - A DTLS handshake takes a fair bit of CPU time,
> especially on the passive (server) peer, and two round trips.  The CPU
> cost might not be that big of a deal (SBC vendors may disagree), but
> round trips hurt.

Yes.  But major web sites seem to accept the performance penalty of the TLS handshake, both CPU hit and round trips.

> Conferencing Scenarios - Ensuring that streams can be mixed,
> translated and still decoded for a multi-leg conference is just easier
> with security descriptions.
> 
> It's true that conferencing scenarios can be addressed by EKT, but EKT
> has similar 2804 properties as security descriptions.  It would not be
> permissible to use EKT for a peer identity bound session because it
> makes the media accessible to signaling intermediaries (read: the web
> site).

To the contrary -- EKT is protected by the DTLS-SRTP key, which is not known to the web site (or SIP proxies).

> As long as you are in that state, EKT doesn't really provide that
> much.  Bid-down protection seems lame when the site has access to the
> keys.

Yes, it is lame if the site has access to the keys.  That is why I don't want Security Descriptions used with RTCWEB.

> Practical Matters of Security - You aren't necessarily more secure
> because you are using DTLS-SRTP.  The complete security story requires
> not just DTLS-SRTP, but also that both peers use identity assertions.
> Otherwise its security properties are basically the same as security
> descriptions.

Agreed.  And DTLS-SRTP provides the foundation to build such a system.  Security Descriptions does not provide a foundation to build such a system.

> The default mode of operation for getUserMedia is to return media that
> is accessible to the web site.  The same for RTCPeerConnection.  That
> means that the site can see and modify your media in your browser,
> even if it can't tamper with it on the network.
> 
> I'm sympathetic to having DTLS-SRTP available to enable these secure
> scenarios.  That's not at issue.  But the reasons for DTLS-SRTP only
> largely come down to just having less code. And seriously, it's not
> even that much less.

-d

> On 25 April 2013 08:57, Cullen Jennings <fluffy@iii.ca> wrote:
>> 
>> The working groups committed some time ago to have a further discussion on whether SDP Security Descriptions (RFC 4568 aka SDES) would be usable as a keying method for WebRTC.  As we prepare for that discussion, we'd like to have expressions of interest or support for that approach which indicate the general outlines of support proposed.  If you wish to make such an expression of support, please send it to the chairs or the list.
>> 
>> Cullen, Magnus, & Ted <The Chairs>
>> 
>> 
>> _______________________________________________
>> 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