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

Christian Groves <Christian.Groves@nteczone.com> Fri, 17 April 2015 01:06 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2976A1A8755 for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 18:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQGsYZuocl4n for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 18:05:59 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9614B1A8742 for <dispatch@ietf.org>; Thu, 16 Apr 2015 18:05:59 -0700 (PDT)
Received: from ppp118-209-40-101.lns20.mel4.internode.on.net ([118.209.40.101]:51429 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <Christian.Groves@nteczone.com>) id 1YiuhT-0004Wa-5T for dispatch@ietf.org; Fri, 17 Apr 2015 11:04:07 +1000
Message-ID: <55305C6F.4020704@nteczone.com>
Date: Fri, 17 Apr 2015 11:05:51 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <55134454.9050302@ericsson.com> <DF642B61-47ED-4F33-BE7F-3F70FF80B294@nostrum.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> <552FFF92.9040709@nostrum.com> <5530069C.3040008@alum.mit.edu>
In-Reply-To: <5530069C.3040008@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/v8-1jkjbVCRz5CtQqoyu6UnBP44>
Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2015 01:06:04 -0000

Hello Paul and Adam,

On 17/04/2015 4:59 AM, Paul Kyzivat wrote:
> On 4/16/15 2:29 PM, Adam Roach wrote:
>> On 4/16/15 13:23, Paul Kyzivat wrote:
>>> The advertisements are send over a data channel.
>>
>> Is this like a "data channel" in the same sense that WebRTC uses that
>> term?
>
> Yes. Chosen in order to facilitate the possibility of WebRTC clients 
> for CLUE.
>
>> If so, I think there are some good ways to handle this in line
>> with PERC's goals (there are reasonable ways to ensure that the data
>> channels terminate at the trusted key management node rather than the
>> mixer).
[CNG] The CLUE datachannel currently is terminated at the mixer. It 
needs to have access to the Advertisements in order for it to formulate 
the Advertisements that sent to other CLUE enabled endpoints.
>
> I fear we are talking past one another.
>
> Conceivably it would be possible to separate the signaling logic of 
> clue from the media mixing logic, so that there could be a *trusted* 
> entity that manages the keys and also does the mixing of clue 
> advertisements, but that offloads the actual media "mixing" (switching 
> in this case) to an untrusted media box.

> But it will require some careful thought, and probably changes to clue.
[CNG] It depends on your ambition level. CLUE v1 can still be used 
albeit in a simpler form. E.g. An endpoint using PERC probably shouldn't 
send XCARD information information about the participants. Basically it 
shouldn't send any metadata it doesn't want a mixer to access. There's 
still quite a few attributes that would be useful for capture selection 
and rendering that I couldn't see a problem with a mixer having access to.
If you want to pass XCARD information etc. securely through a mixer to a 
remote CLUE endpoint via CLUE then that's going to need work in CLUE.
>
> I guess that would be a CLUEv2, and we shouldn't get too hung up on it 
> right now.
[CNG] I do think its still worthwhile discussing as part of the 
architecture how mixing is controlled in a PERC architecture. I think 
its important we're on the same page. CLUE may have a role here.

BTW I do support this work.

Regards, Christian

>
>     Thanks,
>     Paul
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>