Re: [rtcweb] Let's define the purpose of WebRTC

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 09 November 2011 14:32 UTC

Return-Path: <mperumal@cisco.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 ED76B21F8AA8 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.574
X-Spam-Level:
X-Spam-Status: No, score=-8.574 tagged_above=-999 required=5 tests=[AWL=1.725, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 M5EqE-5Q8RAS for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:32:29 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0979621F8A7D for <rtcweb@ietf.org>; Wed, 9 Nov 2011 06:32:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3442; q=dns/txt; s=iport; t=1320849143; x=1322058743; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=g9YWVem0NPX1qbXiUVu0h0KwlMk8kenje1vALIw2gXA=; b=U+/37QJADb9mx9jFSpHrmeRHtV8O+FNbsyyBwYmAGReJL3PZvqlhCz6q L6TW8q4TAMRMdvO7sF31Naey+eEKTejNvG+UX+23WgpD1XW/pTMkbY0QX c8lCNpQEIDEEYzBcvLoEcU+gOjjd99HOPbsYwHCchBnUBsm8oFTj1fGA3 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvMAAImOuk5Io8US/2dsb2JhbABChH2VK450gQKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIGqEKAYxZkkiBMIc5M2MEiAqRWYw8
X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="121182847"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2011 14:32:19 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA9EWIK0027042; Wed, 9 Nov 2011 14:32:18 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 20:02:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 9 Nov 2011 20:02:16 +0530
Message-ID: <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com>
In-Reply-To: <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Let's define the purpose of WebRTC
Thread-Index: Acye5bP4GkdBFI8bRdem3spaqSgpGQAAB0Mw
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <CABw3bnPE=OY_h5bM7GA6wgrXiOBL8P4J0kw1jLv-GSpHAbg=Cg@mail.gmail.com> <CABcZeBNqdkh8u=gwOvKfDCQA7rXdAyQkfaM1r2Sx10787btP6A@mail.gmail.com> <B10FEFF6-0ADC-4DB1-83BB-50A11C65EC35@acmepacket.com> <CABcZeBNSXtim_VqzqAd8Z-u4zWSjaYmsVZPN=7sDYkJsgtRAHA@mail.gmail.com> <4EB7E6A5.70209@alvestrand.no> <F8003BA9-BCD8-4F02-B514-8B883FF90F91@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <CALiegfmf59jb4asUu9LA6YY_aMtKEnM1Wy34KbuLEn3_h1xBXA@mail.gmail.com> <CAL iegfmM1P B=VAQjfh4rW3 -3C8aumHdWy9nZxD0-BWBq9Kq_tg@mail.gmail.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@mail.gmail.com>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
X-OriginalArrivalTime: 09 Nov 2011 14:32:18.0517 (UTC) FILETIME=[6246A850:01CC9EEC]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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: Wed, 09 Nov 2011 14:32:33 -0000

|And what is the advantage? you still say exactly the 
|same: a WebRTC client "MUST" allow plain RTP if the 
|peer is not a WebRTC client. Why is that an argument 
|in favour of non mandating SRTP?

We seem to have a group of people concerned about the cost associated with having to upgrade/replace/supplement their non-SRTP capable gears such as PSTN gateways, and I was sympathetic towards them -:) 

|If I'm in a shared WiFi network and receive a call from 
|a non-WebRTC client not supporting SRTP, my neighbors can 
|intercept it.

If the shared WiFi network hasn't employed WiFi encryption, then you would probably be more concerned with your neighbors intercepting all of your traffic than just RTP -:)

|What does such "STUN extension" provides here?

It would tell the browser that the peer (browser) claims WebRTC compliance and so shouldn't allow insecure calling (the STUN extension is added by the browser and the applications has no control over it).

Muthu

|-----Original Message-----
|From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
|Sent: Wednesday, November 09, 2011 7:14 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson;
|rtcweb@ietf.org
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com>om>:
|> |And what you state is that, in case the peer does not annouce
|> |support for SRTP then the browser should downgrade security
|> |to plain RTP.
|>
|> No, not based on the SRTP capability advertised by the peer, rather based on whether the peer claims
|it is WebRTC compliant (to make sure calls b/w WebRTC clients are always secure).
|>
|> |The user (web visitor) has no way to know whether the WebRTC
|> |application will contact a WebRTC browser or another device
|> |at the media plane.
|>
|> We could add a STUN extension to indicate compliance to WebRTC, including the supported version
|level if we ever come up with WebRTC2.0.
|
|And what is the advantage? you still say exactly the same: a WebRTC
|client "MUST" allow plain RTP if the peer is not a WebRTC client. Why
|is that an argument in favour of non mandating SRTP?
|
|If I'm in a shared WiFi network and receive a call from a non-WebRTC
|client not supporting SRTP, my neighbors can intercept it. What does
|such "STUN extension" provides here? just nothing.
|
|
|
|
|
|--
|Iñaki Baz Castillo
|<ibc@aliax.net>