Re: [rtcweb] New use-case proposed

Magnus Westerlund <> Mon, 14 May 2012 08:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E13D921F85BD for <>; Mon, 14 May 2012 01:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.146
X-Spam-Status: No, score=-106.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P6dkyyDyWu9B for <>; Mon, 14 May 2012 01:35:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F73021F85A0 for <>; Mon, 14 May 2012 01:35:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7bc5ae00000796a-75-4fb0b91f41e4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 52.11.31082.F19B0BF4; Mon, 14 May 2012 09:49:51 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 14 May 2012 09:49:50 +0200
Message-ID: <>
Date: Mon, 14 May 2012 09:49:50 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Harald Alvestrand <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] New use-case proposed
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 May 2012 08:35:53 -0000

On 2012-05-11 18:21, Harald Alvestrand wrote:
> 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.

Actually EKT solves this in a very reasonable way. Each participant
announces his key using EKT. When a participant leaves all the other
participants uses EKT to provide a new key for the media they send. Thus
no need for synchronized key roll over anything.

When it comes to the security aspect this I would say it is part of the
model. SRTP uses symmetric keys, thus anyone can spoof anyone that are
inside the session and having access to the crypt context. In
centralized conferencing it is the central node that enforces the
relation between each other. That can be done both using independent
crypto contexts and having shared one.

And the arguments around the complexity is not that it on a per stream
individual basis is horrible expensive. It is the argument about needing
to have the functionality doing decryption and N-1 encryptions for each
packet being forwarded to all the others in a N number of participants
conference. The argument is to have no need for any media flow
encryption and decryption only be part of the key-management.

> 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.

I am not arguing for including IP multicast support. The issue this use
case brings up is that one of RTP support for multi-party sessions. This
use case makes it clear that a particular level of RTP functionality
support is needed. I think almost the same is needed for centralized RTP
mixer topologies where the middle node uses its own SSRCs to forward
other participants media streams and transfer RTCP feedback messages
when not possible to handle in the mixer.

Another aspect that we need to bring up here is if there is going to be
any support for a WebRTC browser to receive a media stream from A and be
capable of forwarding it to B. Without the same features as needed for
this use case we must mandate that a browser doing this supports media
transcoding. Otherwise congestion control and media control aspects will
not be supported enabling media to be delivered. Transcoding obviously
gives a significant hit on quality unless the media bit-rate is
significantly higher than without transcoding.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: