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

Max Jonas Werner <> Thu, 27 June 2013 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A80FA21F9E92 for <>; Thu, 27 Jun 2013 10:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zxNU0yWaSla4 for <>; Thu, 27 Jun 2013 10:42:06 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 67FF921F9E94 for <>; Thu, 27 Jun 2013 10:42:06 -0700 (PDT)
Received: (qmail 4483 invoked from network); 27 Jun 2013 17:42:03 -0000
Received: from unknown (HELO ? ( by with SMTP; 27 Jun 2013 17:42:03 -0000
Message-ID: <>
Date: Thu, 27 Jun 2013 19:42:02 +0200
From: Max Jonas Werner <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Parthasarathi R <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <2C6DDF0C-201D-4CA3-8EB0-F14B!> <> <> <012d01ce7357$39226ef0$ab674cd0$>
In-Reply-To: <012d01ce7357$39226ef0$ab674cd0$>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MXVDNUSTMMFEFWAIVHXJ"
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: Thu, 27 Jun 2013 17:42:11 -0000


On 27.06.2013 18:56, Parthasarathi R wrote:
> Dan,
> I'm wondering whether any identity is mandatory all for WebRTC session. I'm
> asking this query as lot of WebRTC demo works well without any identity. For
> example: it is possible to pass URL like
> and ask the participant to join the
> session.

whether an application makes use of the identity API is up to the
developer as far as I unterstand the specs. This is why states:

"WebRTC offers and answers (and hence the channels established by
RTCPeerConnection objects) can be authenticated"

I just recently gave a talk on WebRTC security and in the part about
identity I stated that anonymity is a very useful tool to ensure user's
privacy. That's why the identity services should always be optional.


>> -----Original Message-----
>> From: [] On
>> Behalf Of Dan Wing
>> Sent: Friday, June 21, 2013 11:30 PM
>> To: Hadriel Kaplan
>> Cc:
>> Subject: Re: [rtcweb] No Interim on SDES at this juncture
>> 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.
>> -d