Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

[Eric Rescorla <[e-mail]>]

I'm still trying to wrap my head around this problem, but in a general case,
it may not be possible for PERC to support every possible advanced
conferencing
feature and that's OK. Security without any compromises is rare.

And since I haven't said this already: I'm in favor of this effort.

-Ekr


On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat <[e-mail]>
wrote:

> On 4/16/15 2:02 PM, Adam Roach wrote:
>
>> On 4/14/15 08:59, Paul Kyzivat wrote:
>>
>>> On 4/13/15 8:27 PM, Christian Groves wrote:
>>>
>>>> Hello,
>>>>
>>>> Please see below [CNG].
>>>>
>>>> Regards, Christian
>>>>
>>>>> What is the motivation for declaring any extensions to signalling
>>>>>> systems out of scope? (Not saying I see any that need to be
>>>>>> created, but
>>>>>> I'm surprised that it's not something that the group might need to
>>>>>> investigate rather than making that call at chartering time)?
>>>>>>
>>>>>>  My reasons is to keep this WG focused on what it actually needs to
>>>>> produce and not get completely tied up in discussion of exactly how one
>>>>> will integrate this into ones signalling system. So I know people want
>>>>> this in WebRTC and SIP based conferences. I haven't heard anyone saying
>>>>> CLUE, but that is likely. These integrations are quite different,
>>>>> especially in what pieces you will trust when it comes to client
>>>>> software. Thus, my view was that WG working with signalling systems is
>>>>> the ones that should provide any necessary integration towards the
>>>>> framework.
>>>>>
>>>> [CNG] I don't see CLUE being a lot different from normal SIP based
>>>> conferences apart from the RTP header issue raised by Paul K. All CLUE
>>>> is really doing is providing metadata to endpoints to allow them to
>>>> select media captures more intelligently. If an endpoint is using
>>>> private media there may be some consideration of "how much" CLUE
>>>> metadata to provide to a 3rd party switch.
>>>>
>>>
>>> You highlight an interesting point.
>>>
>>> If the goal is for the participants to conference without trusting the
>>> intermediary that does the "switching", then they may also not trust
>>> that intermediary to see the clue metadata that describes the media
>>> and the participants. There might need to be a way for the
>>> advertisements by the endpoints to be encrypted, so that the
>>> intermediary can only collect them and pass them on to the other
>>> endpoints.
>>>
>>
>>
>> These are sent in RTP header extensions, right? RFC6904 lets you encrypt
>> selected header extensions end-to-end. In the current PERC proposals,
>> anything encrypted with RFC6904 would be visible to the participants,
>> but not to the MCU.
>>
>
> No. The advertisements are send over a data channel. In a conference
> usage, they (and the RTP media) are sent to the mixer. Then the mixer can
> consolidate the advertisements it has received, and the corresponding
> media, in any manner it wants. The consolidated advertisements are sent out
> to the participants.
>
> The mixer needs to respond to the advertisements. Doing so it indicates
> which media it wants to receive, which will affect what media it can offer.
> Superficially it is hard to conceive of how a mixer could do its job
> without being able to decode the advertisements it receives.
>
> One possibility for a mixer is to "pass through" a merge of all the
> advertisements it receives to all the other participants - effectively
> treating them as blobs that are combined together. *In principle* it might
> be possible for the mixer to do this without being able to read the
> substance of those advertisements.
>
> But that would certainly require some major redesign of the CLUE
> mechanisms. And even then it wouldn't work for more common usages such as
> where the mixer is making the decisions about switching sources based on
> voice activity.
>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>