Re: [rtcweb] New use-case proposed

Michael Welzl <michawe@ifi.uio.no> Sat, 12 May 2012 08:58 UTC

Return-Path: <michawe@ifi.uio.no>
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 EC3E521F861C for <rtcweb@ietfa.amsl.com>; Sat, 12 May 2012 01:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 Fy94R5qr8dVM for <rtcweb@ietfa.amsl.com>; Sat, 12 May 2012 01:58:31 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3421F85F9 for <rtcweb@ietf.org>; Sat, 12 May 2012 01:58:30 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1ST89l-0006UC-1w; Sat, 12 May 2012 10:58:29 +0200
Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from <michawe@ifi.uio.no>) id 1ST89k-0005s4-Gp; Sat, 12 May 2012 10:58:29 +0200
Message-Id: <18737607-DD2E-44E4-AF48-3DCFB42D3A77@ifi.uio.no>
From: Michael Welzl <michawe@ifi.uio.no>
To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= <goran.ap.eriksson@ericsson.com>
In-Reply-To: <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 12 May 2012 10:58:05 +0200
References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com>
X-Mailer: Apple Mail (2.936)
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 20037 max rcpts/h 45 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 242EC96719B90E5BC98CF80885245EE3BF004B3C
X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 568 max/h 12 blacklist 0 greylist 0 ratelimit 0
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New use-case proposed
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: Sat, 12 May 2012 08:58:32 -0000

On May 11, 2012, at 11:31 PM, Göran Eriksson AP wrote:

>
>
> 11 maj 2012 kl. 22:52 skrev "Harald Alvestrand"  
> <harald@alvestrand.no>no>:
>
>> On 05/11/2012 06:38 PM, Göran Eriksson AP wrote:
>>>
>>> 11 maj 2012 kl. 18:21 skrev "Harald  
>>> Alvestrand"<harald@alvestrand.no>rand.no>:
>>>
>>>> I propose to reject this use case because it requires yet another
>>>> security redesign.
>>>> The clue is here:
>>>>
>>>>> - The keying solution must allow each participants to encrypt to
>>>>> multiple receivers without any decryption+encryption in the  
>>>>> middle node
>>>>>
>>>> This means that each participant must use the same encryption  
>>>> keys to
>>>> all other participants; this in turn means that when someone  
>>>> leaves the
>>>> group, all participants must change their encryption keys; it  
>>>> also means
>>>> that as long as shared keys are used for authentication, all
>>>> participants can impersonate all other participants.
>>>>
>>>> In fact, this solution has most of the issues (except for the  
>>>> network
>>>> layer deployment issue) that leads me to strongly advocate leaving
>>>> multicast out of scope for this effort.
>>> You mean for this phase of webrtc std efforts or for ever?
>> Until we've got an usage scenario with a deployment story that I find
>> credible.
>>
>> The point I'm pretty vehement on - that lack of multicast support  
>> should
>> not be a blocker for finalizing the specs we are working on.
>>
>
> I am pretty sensitive to such consequence as well! Having said that,  
> enabling innovation in this kind of application category is  
> important  for the long term evolution of the web platform.
>
> Personally, I would like to us to ensure we have at least have a  
> good foundation for multicast later.

+1 (to both parts of this)

Cheers
Michael