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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 16 April 2015 18:59 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 978DD1B34B5 for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 11:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 Si5Jmw6kPCvC for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 11:59:42 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7AF1B34B4 for <dispatch@ietf.org>; Thu, 16 Apr 2015 11:59:42 -0700 (PDT)
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-01v.sys.comcast.net with comcast id Gizd1q0012XD5SV01izhPx; Thu, 16 Apr 2015 18:59:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id Gizh1q00A3Ge9ey01izhPW; Thu, 16 Apr 2015 18:59:41 +0000
Message-ID: <5530069C.3040008@alum.mit.edu>
Date: Thu, 16 Apr 2015 14:59:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>, 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>
In-Reply-To: <552FFF92.9040709@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429210781; bh=fqLo+s1lx6Al0e9RmVuBp28XM/R1blivyosQZjLB60M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ixebC8P7MkvWeBZCN+63I65aDgnkYeNIcRIQxG8HXhKSYQD7eqKPBMVTjfyscC1+X wHkhKztfDhUiJ1MZaegGZ89UbTvhhc+AXvDqT9Wap2a7zeaTDgYFl4oJnQHWtWCYlD brrVYkBEVRAartbo5PYtuMHXwqECch1kZY61jaEdF6+D5xNwucQm2WOgpO1udMzxSB OrfjMYWYmJnSIIbBQijEOdRNgauFGgTETyL/8E3rhUP6pWRBOgV+RYXRzhToZfI++4 FDTDmHWwz7w+f0rX4Q7za6UTy+yCrkswrG0QOIbV23Rd/CJJ3Xlnojvv16AuR8/KrR rbCSPJCfM0rzw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/jC5RoKoXkYJTthy_ZActR9pja9o>
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: Thu, 16 Apr 2015 18:59:43 -0000

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).

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.

I guess that would be a CLUEv2, and we shouldn't get too hung up on it 
right now.

	Thanks,
	Paul