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

Max Jonas Werner <mail@makk.es> Sun, 23 June 2013 12:52 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 D946B21F9D4E for <rtcweb@ietfa.amsl.com>; Sun, 23 Jun 2013 05:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.440, 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 7+jwsGuSOoyT for <rtcweb@ietfa.amsl.com>; Sun, 23 Jun 2013 05:51:57 -0700 (PDT)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 6341F21F99D3 for <rtcweb@ietf.org>; Sun, 23 Jun 2013 05:51:56 -0700 (PDT)
Received: (qmail 23314 invoked from network); 23 Jun 2013 12:51:53 -0000
Received: from unknown (HELO ?192.168.0.20?) (31.18.98.41) by lupus.uberspace.de with SMTP; 23 Jun 2013 12:51:53 -0000
Message-ID: <51C6EF5F.60405@makk.es>
Date: Sun, 23 Jun 2013 14:51:43 +0200
From: Max Jonas Werner <mail@makk.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.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-F14B8A2D5758@cisco.com>
In-Reply-To: <2C6DDF0C-201D-4CA3-8EB0-F14B8A2D5758@cisco.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CTQQXMSFJXNRAFXNORFN"
Cc: "<rtcweb@ietf.org>" <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: Sun, 23 Jun 2013 12:52:03 -0000

On 21.06.2013 18:45, Dan Wing wrote:

> On Jun 20, 2013, at 7:58 PM, Hadriel Kaplan <hadriel.kaplan@oracle.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.

draft-ietf-rtcweb-security-arch-06, section 5.6 talks quite clearly
about verifying peer identities (without concentrating on a signalling
protocol like SIP) so if you would want to have secure communication
(even with a signalling server you don't trust) _and_ verified peers a
combination of DTLS-SRTP and the mentioned peer authentication mechanism
in draft-ietf-rtcweb-security-arch-06 would be a must.

As far as I understand it, SDES cannot provide the same level of
end-to-end security under the assumption that you don't trust the
signalling server.

Max