Re: [rtcweb] New use-case proposed

[Magnus Westerlund <[e-mail]>]

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------