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

Roman Shpount <roman@telurix.com> Wed, 09 November 2011 14:33 UTC

Return-Path: <roman@telurix.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 424E921F8C0A for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.741
X-Spam-Level:
X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 oAkE7XuQOHi9 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:33:14 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE721F8B37 for <rtcweb@ietf.org>; Wed, 9 Nov 2011 06:33:14 -0800 (PST)
Received: by qyk32 with SMTP id 32so1632317qyk.10 for <rtcweb@ietf.org>; Wed, 09 Nov 2011 06:33:14 -0800 (PST)
Received: by 10.224.174.68 with SMTP id s4mr2206840qaz.4.1320849193868; Wed, 09 Nov 2011 06:33:13 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id cd3sm5183827qab.5.2011.11.09.06.33.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Nov 2011 06:33:12 -0800 (PST)
Received: by ywt2 with SMTP id 2so2147293ywt.31 for <rtcweb@ietf.org>; Wed, 09 Nov 2011 06:33:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.23.130 with SMTP id m2mr5423157pbf.120.1320849192087; Wed, 09 Nov 2011 06:33:12 -0800 (PST)
Received: by 10.68.62.170 with HTTP; Wed, 9 Nov 2011 06:33:11 -0800 (PST)
In-Reply-To: <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@mail.gmail.com>
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> <CALiegfmM1PB=VAQjfh4rW3-3C8aumHdWy9nZxD0-BWBq9Kq_tg@mail.gmail.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@mail.gmail.com>
Date: Wed, 9 Nov 2011 09:33:11 -0500
Message-ID: <CAD5OKxvQYVKOZF88WLCiRseg-qXQdOpKeDU_t9b-yA2GcDBT-w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=bcaec5215d37e571ea04b14e2a15
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:33:15 -0000

On Wed, Nov 9, 2011 at 8:44 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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?
>
>
What I have not seen on this list is why SRTP must be used for all the
calls. The things I've seen so far:
1. SRTP must be used everywhere since security is good
2. We are innovative so we must use SRTP everywhere
3. We do not trust the user or the application so we must use SRTP
everywhere
4. We must have SRTP in order to have consensus.

I think except the fact that security is generally a good thing, non of
these arguments are relevant.

What I was trying to say that there are number of situations where:

1. SRTP is useless: If we do not trust the application (application is
delivered over HTTP), there is no point to encrypt the media. Application
can send this media to some box in the middle and record it, without user
ever knowing. Requiring SRTP in this case is almost like trying to lock the
window when your door is open.

2. SRTP is not required: If we are dealing with a greeting card application
or game chat, no one expects security. If security can be provided this
will probably not hurt anybody, but in the end it will serve no purpose
there.

3. SRTP is undesirable: As I've mentioned before there are places and
situations where encryption is either makes things more difficult (like
interop with legacy devices, debugging, or building new software). In these
cases, having SRTP as a must just introduces a higher barrier to entry the
needs to be overcome in order to communicate with WebRTC. This is not
something critical, but it will make things more difficult and will work
against innovation.

4. SRTP is illegal: I am not talking about wiretapping. I do not propose to
create any types of back doors in WebRTC in order to intercept the
communications. All I am saying that application developer should have an
option not to encrypt its traffic to comply with local laws or regulations.
I do not think there is a single user faced communication protocol that
does not provide a non secure alternative (HTTP vs HTTPS, SMTP and IMAP
over TCP vs TLS, etc). I do not see why WebRTC must be the first protocol
not to have an unencrypted option.

What I would propose is to allow RTP communications from sessions initiated
by HTTP and require SRTP (or a user consent) for sessions started from
HTTPS. This should be similar to current HTTPS vs HTTP model for
javascript, and will require security where it will do some good vs places
where it is going to be useless.
_____________
Roman Shpount