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

Dan Wing <> Fri, 10 May 2013 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06DAE21F9428 for <>; Fri, 10 May 2013 15:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4LSVQZy+vPrO for <>; Fri, 10 May 2013 15:48:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 020F721F9355 for <>; Fri, 10 May 2013 15:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2329; q=dns/txt; s=iport; t=1368226131; x=1369435731; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9gGW67Ez6XHHr8Y9HhVmjKROLNBamiwzW3X2Cxz2leI=; b=bFoqgt5kZu6ylggcuOQus2u8BZwUfDJogUGXcOhUt4g3xR08a9EObcV5 FfKEwUqawGCuXs1n3fgtCU+/WwdsWc2NSHDEYadwnYLx+sY66h7BELNED kbYIBv41V3QxWHKwOKKy8pB/WwKXW9AQrFoRZO6/Jb/k1rU2xqPFfM/F6 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAD54jVGrRDoH/2dsb2JhbAA8DQmDBzfAIHsWdIIfAQEBAwF5BQsLDgoTG1cGE4gGBQ29PI1eD4EIMweCdGEDiRqIBYI+g0+GFosfgy8c
X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="77730723"
Received: from ([]) by with ESMTP; 10 May 2013 22:48:48 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id r4AMmmg1011841; Fri, 10 May 2013 22:48:48 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing <>
In-Reply-To: <>
Date: Fri, 10 May 2013 15:48:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Cullen Jennings <>
X-Mailer: Apple Mail (2.1503)
Cc: "" <>
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 May 2013 22:48:57 -0000

On May 10, 2013, at 11:44 AM, Cullen Jennings <> wrote:

> On May 6, 2013, at 8:56 AM, Dan Wing <> wrote:
>> On May 6, 2013, at 7:30 AM, Henry Lum <> wrote:
>>> Chiming in late.
>>> Speaking from a contact center perspective, a lot of calls are required to be recorded. In order to allow active recording (such as SIPREC), the contact center has to provide a media endpoint for bridging media so that a copy of the media can be created. The users will have to trust the contact center to handle the media anyways, and the media must be decrypted and re-encrypted by some media element within the contact center to perform recording. To me DTLS-SRTP-EKT does not provide any additional benefit over SDES for this type of use case.
>> Only DTLS-SRTP proves the call is actually to the call center (bank, stock broker, reservation company). 
> Uh, can you say a bit more about how DTLS-SRTP provides that?  

The certificate can be verified using an identity provider.  That can be a company like OneID, Facebook, a classic Certificate Authority, a privately-maintained list of previous certificates we used for that same identity (e.g., in my own addressbook, similar to the mechanism described by ZRTP), network notaries (similar to  Identity can also be provided by the WEBRTC operator if the is sufficient (e.g., facebook can be the identity provider for facebook users).  The strength of this model is the identity provider can be anyone, so if a user wants to verify identity with a 3rd party, they can.

> The topic of how this is done and if it reduces to the same security as SDES has been controversial and would be good to get people understanding the issues her

Without separate identity, a bank or healthcare provider will be unable to certify their identity to a 3rd party (my local addressbook, Facebook, a network notary service, etc.).  Instead, their identity would be attested by whatever entity originates or terminates the RTCWEB session, and the user and the browser have no basis to build a stronger, more robust system to protect against such abuse.