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

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 10 November 2011 21:07 UTC

Return-Path: <HKaplan@acmepacket.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 8C52B11E8083 for <rtcweb@ietfa.amsl.com>; Thu, 10 Nov 2011 13:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
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 byo3BF8xOkcy for <rtcweb@ietfa.amsl.com>; Thu, 10 Nov 2011 13:07:16 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E16B111E807F for <rtcweb@ietf.org>; Thu, 10 Nov 2011 13:07:15 -0800 (PST)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Nov 2011 16:07:14 -0500
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 16:07:14 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] Let's define the purpose of WebRTC
Thread-Index: AQHMn+y34GF827+x8UmM90+XdaVv7A==
Date: Thu, 10 Nov 2011 21:07:13 +0000
Message-ID: <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.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> <CAD5OKxvQYVKOZF88WLCiRseg-qXQdOpKeDU_t9b-yA2GcDBT-w@mail.gmail.com> <CABcZeBOiPxz_swdaG6Aqoch1WAUtjNh4eOQy1QObCDXT_B8azg@mail.gmail.com>
In-Reply-To: <CABcZeBOiPxz_swdaG6Aqoch1WAUtjNh4eOQy1QObCDXT_B8azg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <E0D16B5B59F2FD439AA5A6A048F13002@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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: Thu, 10 Nov 2011 21:07:16 -0000

On Nov 10, 2011, at 12:20 AM, Eric Rescorla wrote:

> I can envision situations on which security would be desirable in both of
> these applications. In the case of a "greeting card application" (whatever
> that is) my greeting card might contain sensitive personal or medical
> information (congratulations on your pregnancy, sorry to hear you have
> cancer etc.) Surely I do in fact want that information secured. Similarly,
> it might not be important to have my Farmville chats secure, but if the
> purpose of an in-game chat is for me and my co-player to cooperate
> in a game where money is on the line (e.g., a tournament), then suddenlu
> security becomesmuch more important. Not to mention that the players
> may simply be using in-game chat to discuss personal stuff.

I think that's a red herring.  Just because you as a user could post your social security number on a forum website, for example, does not mean all forum websites should use HTTPS "just in case".  Because even if they used HTTPS it's not going to secure your social security number from being read by anyone else, nor does the forum website claim to provide any such form of confidentiality to begin with. 

The greeting card case, for example, is going to record your media on some server somewhere - just because they use SRTP from you to do so doesn't mean they're going to prevent everyone on the planet from being able to access the greeting card; or even if they only allow authorized users to listen to the greeting card, it doesn't mean that they won't simply use an HTTP'ed wav file to deliver it to them.  Obviously if a greeting card app *wants* to provide that sort of confidentiality/privacy, then it can and should use SRTP as well as encrypt everything else, control authorization, etc.  That's their choice, based on what type of application they want to provide.  We don't need to create a nanny state.

> 
> The point is that it's very hard to anticipate which communications media
> will be used for sensitive information. To say "we don't need security
> in this application because nobody will ever use it to discuss sensitive
> stuff" is short-sighted. Better simply to be secure all the time.


And one could argue this the exact opposite - if the browser shows some lock-icon thing for SRTP, then it's better for them to use RTP instead for such apps, so as not to make you think the service as a whole is secure if it really isn't. The only one who knows the type of application service security model being offered is the Web server admin/developer, not the IETF. 

-hadriel