Re: [rtcweb] No Interim on SDES at this juncture

Dan Wing <> Fri, 21 June 2013 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 135B911E81A7 for <>; Fri, 21 Jun 2013 11:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.256
X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqUQ+iW7WdUT for <>; Fri, 21 Jun 2013 10:59:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2942D11E8193 for <>; Fri, 21 Jun 2013 10:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2730; q=dns/txt; s=iport; t=1371837596; x=1373047196; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=59K9AFcEnH8MXwMMrCgYoaMQbd9xv3/ETcn/bTs+et0=; b=gb0RLYU/kRG2UNlnk34CgPyEQ2SVmF6Jv+SXEUBS2frV6qQWqKNj//X4 5S0vnyTDHZnnZa07ZKgJWVoNcaq+9TSIcUOEakkfYefukZnd3xEPjH5BW h5n1g8yII/Jh/6Il8A5mZZt97yZ616UzcoW6AjXYdYyXfs/pCUU3BOqOh s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAD2UxFGrRDoI/2dsb2JhbABSCYMJwC+BBRZ0giMBAQEDATo/EAsYLlcGE4gIBbxXjg6BCDMHgwBhA4khjiKRRIMvHA
X-IronPort-AV: E=Sophos;i="4.87,914,1363132800"; d="scan'208";a="80994055"
Received: from ([]) by with ESMTP; 21 Jun 2013 17:59:53 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5LHxrmr029720; Fri, 21 Jun 2013 17:59:53 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <>
In-Reply-To: <>
Date: Fri, 21 Jun 2013 10:59:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <2C6DDF0C-201D-4CA3-8EB0-F14B!> <>
To: Hadriel Kaplan <>
X-Mailer: Apple Mail (2.1508)
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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, 21 Jun 2013 18:00:02 -0000

On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan <> wrote:

> On Jun 21, 2013, at 12:45 PM, Dan Wing <> wrote:
>>> We've talked about that one before I think.  If jQuery is out to get you, it's game over.  It's essentially equivalent to a malicious web-server, except of course that the operator of the web-server isn't intending to be malicious (which is an important distinction).  But again, not only does jQuery have access to information such as who you're talking to and when, it can also redirect your media to a gateway of its choosing to terminate the DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff.
>> For the attacker to succeed with the redirection of DTLS-SRTP to a server it controls, the attacker would also need to modify the SDP's a=fingerprint line which is as  trivial as the attacker's other SDP modifications.  To prevent the attacker from succeeding with such modification, we need cryptographic identity (to protect the From/To/Date/a=fingerprint and other fields), and need the browser (not JS) to verify the identity using an external service (e.g., local disk, IdP separate from the web server providing us the (compromised) JS and the SDP).  While it is true that today we don't have a way today to provide that cryptographic identity (RFC4474 does not work, draft-wing-rtcweb-identity-media written by me and Hadriel was met with silence) DTLS-SRTP creates the foundation to build cryptographic identity which can be verified by the browser itself.  Such cryptographic identity protects from this specific attack, and DTLS-SRTP protects from other attacks.
> I agree - when we have such a thing, using DTLS-SRTP will have much more meaning.  But (1) there is no such thing yet, and (2) it won't make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway scenarios we're talking about, since the DTLS isn't going end-to-end.  I.e., none of the calls would successfully authenticate using such an out-of-band mechanism, even the good ones.
> [note though I'm not saying DTLS-SRTP is useless today - quite the contrary, I hummed in favor of making it MTI back when that was decided, and I still think it should be MTI]

Will the existence of SDES prevent WebRTC from building this more secure system with strong identity?  That is, when we add cryptographic identity will that be effective to prevent a bid-down attack from DTLS-SRTP to SDES?  I am thinking right now that when we add identity we can prevent that bid-down, so at that time SDES could become a proper second-class citizen.