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

[Adam Roach <[e-mail]>]

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.

/a