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

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 20 June 2013 07:11 UTC

Return-Path: <hadriel.kaplan@oracle.com>
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 212C721F9EB6 for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 00:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.557
X-Spam-Level:
X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 AJ1c4g52T3AA for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 00:11:16 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8F21F9C58 for <rtcweb@ietf.org>; Thu, 20 Jun 2013 00:11:16 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5K7BCYQ028381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 07:11:13 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5K7BBm1021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 07:11:12 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5K7BBNt011616; Thu, 20 Jun 2013 07:11:11 GMT
Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-124.vpn.oracle.com (/10.154.166.124) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 00:11:11 -0700
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <CAL02cgQMkHu-NqEeScT2ObfknJ+3OjXi7Y=7rUJtqeu3CbewMQ@mail.gmail.com>
Date: Thu, 20 Jun 2013 03:11:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.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>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
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: Thu, 20 Jun 2013 07:11:22 -0000

On Jun 19, 2013, at 8:58 PM, Richard Barnes <rlb@ipv.sx> wrote:

> I think we still disagree on the scenario.  I've tried to sketch out the full sequence of operations to be clear.  (WebSequenceDiagrams source below.)
> <http://goo.gl/uRi0W>
> 
> ISTM that there are two major differences:
> -- In the SDES case, the JS and the Web Server both have access to the media keys.  In the EKT case, the browser handles the keying update directly.
> -- In the EKT case, the PBX/gateway has to be in the media path to do EKT.  After EKT, it just switches packets (it's basically a TURN server).
> 
> So it seems like a security benefit for EKT and a performance benefit for SDES.  Your quantitative valuation of these benefits / costs may vary.

I'm confused.  EKT has "a security benefit" for whom, exactly?
It's not more secure for the browser user, since a malicious web server can simply *be* the PBX, terminate DTLS-EKT and get the key and the browser user would never know it.
It's not more secure for the SIP user, since the SIP user is only doing SDES and has no idea what's happening on the far-end.

Who are you saying is being better protected from what?

I suppose we could claim the owner of the PBX feels more secure, if they're not the same as the owner of the web-server and don't trust the web-server.  But again, if the web-server owner is malicious it will just terminate the media pretending to be the PBX on one side, and pretending to be the browser to the real PBX on the other side.  And why would a PBX owner accept calls from a web-server it doesn't trust to begin with?

Afaict, the main security benefit of DTLS-EKT is the same as that of DTLS-SRTP: the keys aren't sent in the JSON/SDP/whatever, so they can't be sniffed even if cleartext HTTP is used.  So in a weird way, the security benefit of it is it let's us use an insecure HTTP transport for the JSON/SDP/HTML/whatever.  Luckily the ability to see and modify what goes on there is no big deal... like for example be able to insert a malicious DTLS-SRTP B2BUA that records everything.  Oh, wait...

-hadriel