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

[Paul Kyzivat <[e-mail]>]

On 4/16/15 2:28 PM, Eric Rescorla wrote:
> 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.

I agree.

	Thanks,
	Paul

> 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]
> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>