IETF Logo Mail Archive

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

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Thu, 20 June 2013 21:25 UTC

Return-Path: <andrew.hutton@siemens-enterprise.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 C20C321F919D for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 14:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level:
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=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 i29Tlls0ptKB for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 14:25:47 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A681721E80CD for <rtcweb@ietf.org>; Thu, 20 Jun 2013 14:25:42 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A23921EB8452; Thu, 20 Jun 2013 23:25:21 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 23:25:21 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] No Interim on SDES at this juncture
Thread-Index: AQHObVFVBYzpHvj1BUGlhj09l8oaqpk+DoOAgAEDiyD//+OAgIAAIqoA
Date: Thu, 20 Jun 2013 21:25:20 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D2E8D@MCHP04MSX.global-ad.net>
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> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <9F33F40F6F2CD847824537F3C4E37DDF115D2D76@MCHP04MSX.global-ad.net> <CAD5OKxvMGD=e3rHta9aLRAOAM022V0hzcp6nJbmG+GAxBohS6g@mail.gmail.com>
In-Reply-To: <CAD5OKxvMGD=e3rHta9aLRAOAM022V0hzcp6nJbmG+GAxBohS6g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF115D2E8DMCHP04MSXglobal_"
MIME-Version: 1.0
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 21:25:52 -0000

Communication with an untrusted server is always insecure, even if using DTLS-SRTP, it is surely the level of risk that is the issue and the problem to solve is how the browser indicates that to the user.

Using SRTP is always more secure than using plain RTP but again I think the problem to be solved is how the user is notified about the level of risk.

Regards
Andy








From: Roman Shpount [mailto:roman@telurix.com]
Sent: 20 June 2013 21:58
To: Hutton, Andrew
Cc: Hadriel Kaplan; Richard Barnes; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Subject: Re: [rtcweb] No Interim on SDES at this juncture

On Thu, Jun 20, 2013 at 4:52 PM, Hutton, Andrew <andrew.hutton@siemens-enterprise.com<mailto:andrew.hutton@siemens-enterprise.com>> wrote:
Agree with Hadriel here I so no additional security benefit for EKT given that any media gateway is going to be in cahoots with the webserver and has access to the key.

So all we are left with is the performance benefit of using SDES support in the browser which is significant and reduces the barrier to deploying WebRTC so let's go for the option that is easy to specify, easy to deploy, cheap to implement (already exists in Chrome), and we are all familiar with.

SDES support looks like the obvious choice.

Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicating with a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable from security point of view, then how is SRTP acceptable?
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email