Re: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT)

"Paul E. Jones" <paulej@packetizer.com> Wed, 15 May 2019 02:45 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11BB1201D0; Tue, 14 May 2019 19:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
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 nbPh5AXBOXaH; Tue, 14 May 2019 19:45:05 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53C912003E; Tue, 14 May 2019 19:45:04 -0700 (PDT)
Received: from authuser (localhost [127.0.0.1])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1557888300; bh=S2lZlG6ASiYnjpQbiwWXyCLrGlVwk9PapIOrKcLzYbo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=t/lQ6t8eOMhuDv5nMjKMtcOB/o8l0x4EBxsA2SjjAfI9w+CvpppXMcbany2+Ea7ep S1ic/QlR8mCZ0vIEf6Gke4rZSrBxKDMtky+iU4ZXVMIr8uwxXCHefyMlP3W9vkk4We R+kl7TXoRUyQtfcjoPu2jTxMO53aW2e1tZVY5o2E=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org
Date: Wed, 15 May 2019 02:44:56 +0000
Message-Id: <em538cb28a-f3d5-4bbc-a1c9-24d7798ea916@sydney>
In-Reply-To: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com>
References: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBD1DECFC2-9E12-4D7A-BFA7-9D58AC359074"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/fusiRs_zJnBeWv7ondmwB1GkTnU>
Subject: Re: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 02:45:07 -0000

Barry,

Thanks for the comments.  I accepted all of the suggestions and answered 
the one question below (while also making changes to the text to make 
this clear ... or attempt to do so).


>— Section 4.1 —
>It’s not clear from the diagram or explanation, so please clarify for me: there
>one e2e key per endpoint, and every endpoint knows the key for all the other
>endpoints, yes? I think it would be worth saying this clearly and explicitly,
>either here (my preference, to set it up early) or in Section 4.5.

There is one or more unique E2E keys per Endpoint, generally one per 
media flow (though the same E2E key could be used for all flows given 
the SSRCs are different for each). For each flow, these keys are 
conveyed by the sender in the full EKT Field as per the EKT Diet 
document.

I've added some text and hopefully that will appear in the next 
revision. I also felt like we needed to augment 4.5 with stating (just 
for completeness) that normal DTLS-SRTP is used to obtain HBH keys 
between Media Distributors. So I added that, too.

Paul