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

"Olle E. Johansson" <oej@edvina.net> Wed, 09 November 2011 09:42 UTC

Return-Path: <oej@edvina.net>
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 C03E921F8A6C for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 01:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level:
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
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 56JusqRMV3CP for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 01:42:05 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 372CB21F8A66 for <rtcweb@ietf.org>; Wed, 9 Nov 2011 01:42:05 -0800 (PST)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id D399F754BD1C; Wed, 9 Nov 2011 09:42:01 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <CALiegfmf59jb4asUu9LA6YY_aMtKEnM1Wy34KbuLEn3_h1xBXA@mail.gmail.com>
Date: Wed, 09 Nov 2011 10:42:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <99C883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net>
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>
To: Iñaki Baz Castillo <ibc@aliax.net>
X-Mailer: Apple Mail (2.1251.1)
Cc: "rtcweb@ietf.org" <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 09:42:05 -0000

9 nov 2011 kl. 10:34 skrev Iñaki Baz Castillo:

> 2011/11/9 Avasarala, Ranjit <Ranjit.Avasarala@polycom.com>:
>> I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the browser very bulky.
> 
> Including TLS in a browser makes it bulky? Then we must discourage
> HTTPS usage, right?
> In the other side, have you really measured how much expensive SRTP
> is? it's not at all.
This kind of argument is just a no-op. We need to be able to move forward and as Eric has said on this list, these arguments against encryption is no longer valid.
You could use this against HTTP clients in SIP (SIP identity) and the whole ICE engine too. Moore's law is always helping :-)

> 
> 
>> It would be better to provide a mechanism in the signaling protocol that browser supports to negotiate the desired security mechanism (depending on application requirement) and then use that mechanism (which is part of the system).
> 
> The "application" is untrusted by nature, and we don't want to make
> the end-user to decide whether to trust it or not. Explained many
> times in this maillist.

Agree, we have explained this a number of times. If we leave this up to the web developers and users, we'll end up in trouble.

/O