IETF Logo Mail Archive

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

Adam Roach <adam@nostrum.com> Thu, 25 April 2013 22:20 UTC

Return-Path: <adam@nostrum.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 2CF8521F96DF for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 15:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.001
X-Spam-Level:
X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, 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 ip1ML-omilNb for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 15:20:24 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A56BD21F96BC for <rtcweb@ietf.org>; Thu, 25 Apr 2013 15:20:24 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3PMKHAK024837 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 17:20:18 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5179AC21.5060708@nostrum.com>
Date: Thu, 25 Apr 2013 17:20:17 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <AE1A6B5FD507DC4FB3C5166F3A05A48416281FDB@tk5ex14mbxc272.redmond.corp.microsoft.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <CABkgnnWQZ+5aP0pQRB5Wx9v7pViw4dtd2Hrz6Zwn2XooSkwtvA@mail.gmail.com>
In-Reply-To: <CABkgnnWQZ+5aP0pQRB5Wx9v7pViw4dtd2Hrz6Zwn2XooSkwtvA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
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: Thu, 25 Apr 2013 22:20:25 -0000

On 4/25/13 17:11, Martin Thomson wrote:
> Data channels can continue to use DTLS even though media is encrypted 
> using keys provided by security descriptions.

The arguments for SDES fall into two categories, AFAICT: (1) Those 
required for interop with legacy devices, and (2) those which we are 
prohibited by RFC 2804 from considering. And there is no possible way 
DataChannels are going to interop with legacy devices.

I agree with Alan that we shouldn't make accommodations to use SDES for 
the brower-to-browser case. By implication, this means that the presence 
of DataChannels necessarily means that we're using DTLS-SRTP for the 
whole session. Given those assumptions, the mixed-session scenario you 
describe does not arise.

/a

v2.23.0 | Report a Bug | By Email