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

Max Jonas Werner <mail@makk.es> Thu, 27 June 2013 17:42 UTC

Return-Path: <mail@makk.es>
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 A80FA21F9E92 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 10:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxNU0yWaSla4 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 10:42:06 -0700 (PDT)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 67FF921F9E94 for <rtcweb@ietf.org>; 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 ?192.168.0.20?) (31.18.98.41) by lupus.uberspace.de with SMTP; 27 Jun 2013 17:42:03 -0000
Message-ID: <51CC796A.5030507@makk.es>
Date: Thu, 27 Jun 2013 19:42:02 +0200
From: Max Jonas Werner <mail@makk.es>
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 <partha@parthasarathi.co.in>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C78AD@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgTFSbYSX7v3q37tsjzaPMshyyBroGWr=qmy-HGm82GJFg@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7EF8@TK5EX14MBXC273.redmond.corp.microsoft.com> <CAL02cgQMkHu-NqEeScT2ObfknJ+3OjXi7Y=7rUJtqeu3CbewMQ@mail.gmail.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <CAL02cgT3KEb0VB9kz=QCe7Mt3oj5tZvZouFe5-Uy90Cmm0H0dQ@mail.gmail.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <CAL02cgSS1e5zH2YRh4uTb8qxXF5Ng5y8RxRw-bGP5xmQLkiQ+Q@mail.gmail.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> <2C6DDF0C-201D-4CA3-8EB0-F14B! 8A2D5758@cisco.com> < CA2956C0-56B7-47E9-9EF4-9D639F8B8AD6@oracle.com> <12C17BE5-2302-48E9-A745-5B7265E83E8E@cisco.com> <012d01ce7357$39226ef0$ab674cd0$@co.in>
In-Reply-To: <012d01ce7357$39226ef0$ab674cd0$@co.in>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MXVDNUSTMMFEFWAIVHXJ"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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, 27 Jun 2013 17:42:11 -0000

Partha,

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
> https://apprtc.appspot.com/?r=06095338 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
http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity 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.

Max


>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Dan Wing
>> Sent: Friday, June 21, 2013 11:30 PM
>> To: Hadriel Kaplan
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] No Interim on SDES at this juncture
>>
>>
>> On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan
>> <hadriel.kaplan@oracle.com> wrote:
>>
>>>
>>> On Jun 21, 2013, at 12:45 PM, Dan Wing <dwing@cisco.com> 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