Re: [Perc] I-D Action: draft-ietf-perc-private-media-framework-08.txt

"Paul E. Jones" <paulej@packetizer.com> Thu, 31 January 2019 01:41 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 42475124D68; Wed, 30 Jan 2019 17:41:11 -0800 (PST)
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 O_u7iEyQ0bdT; Wed, 30 Jan 2019 17:41:08 -0800 (PST)
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 3DEC3126CC7; Wed, 30 Jan 2019 17:41:07 -0800 (PST)
Received: from authuser (localhost [127.0.0.1])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1548898865; bh=vYFrJ2sFkhefrOiAOrb9UKj5my60azkTLB0NQaB/PvI=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=qvzG1y5cJVU+bUCcEHwNyKPutAb+pPfQuSZbOJ5uzzEWeil1XG71G31pCqVM9wByi KJD0HdbZrgdv3DyhlcuoHU2tyv9TvmCEGlooODo84wPzll0h63azYH14rdr/xA0CuS rPaVp6CJrWDI8AVUAZeQ97Z5KSEucVIrumBThQRw=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Ben Campbell <ben@nostrum.com>, perc@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org
Date: Thu, 31 Jan 2019 01:41:03 +0000
Message-Id: <emed72b1b6-fbb2-4844-815b-f7bc28a45796@sydney>
In-Reply-To: <3A1F17C6-6849-4354-8CE7-FC69C49D77EF@nostrum.com>
References: <154826948191.7542.12732292886038443439@ietfa.amsl.com> <3A1F17C6-6849-4354-8CE7-FC69C49D77EF@nostrum.com>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.2.34208.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB64DBFE57-2ECB-4BD9-92F3-0C537A7162D0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/hZqRk4laILzOQUfSsUIHG-QPJ58>
Subject: Re: [Perc] I-D Action: draft-ietf-perc-private-media-framework-08.txt
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: Thu, 31 Jan 2019 01:41:11 -0000

Thanks! I'll keep this message in my inbox and make changes as requested 
when creating the next version.

For the "The text was removed. I assume the authors decided it was not 
specific to PERC?" question:

I got agreement to remove it. PERC is intended to (and does) provide 
end-to-end authentication, and the procedures spell out what 
intermediaries (trusted or otherwise) are supposed to do HBH. This text 
seemed to suggest there is something special in this case when there 
isn't. It seemed to add no value, clearly caused confusion, and we could 
not figure out why it was there in the first place.

Paul

------ Original Message ------
From: "Ben Campbell" <ben@nostrum.com>
To: perc@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.org
Sent: 1/30/2019 7:29:20 PM
Subject: Re: [Perc] I-D Action: 
draft-ietf-perc-private-media-framework-08.txt

>Hi,
>
>This version is much better than 07. Thanks for the work on that. I think it’s now ready for IETF Last Call. I will request that shortly.
>
>I have a few new minor editorial comments that can be addressed along with any IETF LC feedback.
>
>Thanks!
>
>Ben.
>
>——————
>
>- (Nit) §1, 2nd paragraph:  The new text addresses my concern, but it added a comma splice. I suggest making the text starting with "this draft aims…” into its own sentence.
>
>
>- Previous Comment:
>
>>
>>  §3.1.2, last paragraph: "In any deployment scenario where the call processing function is
>>  considered trusted, the call processing function MUST ensure the
>>  integrity of received messages before forwarding to other entities.”
>>
>>  Please describe why that is important in a PERC environment.
>
>The text was removed. I assume the authors decided it was not specific to PERC?
>
>
>- (Nit) §4.5.2, 3rd paragraph:
>
>  The change resolves my concern, but I have one editorial suggestion:
>
>OLD:
>When a Key Distributor decides to re-key a conference, it transmits a new EKTKey message [
>I-D.ietf-perc-srtp-ekt-diet  to each of the conference participants containing the new EKT Key.
>NEW:
>When a Key Distributor decides to re-key a conference, it transmits a new EKTKey message
>containing the new EKT Key [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.
>
>- (Nit): New §6.1: "While the number key types is very small”
>s:/“number key types”/“number of key types"
>
>
>
>>  On Jan 23, 2019, at 12:51 PM, internet-drafts@ietf.org wrote:
>>
>>
>>  A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the Privacy Enhanced RTP Conferencing  WG of the IETF.
>>
>>         Title           : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing
>>         Authors         : Paul E. Jones
>>                           David Benham
>>                           Christian Groves
>>  	Filename        : draft-ietf-perc-private-media-framework-08.txt
>>  	Pages           : 24
>>  	Date            : 2019-01-23
>>
>>  Abstract:
>>    This document describes a solution framework for ensuring that media
>>    confidentiality and integrity are maintained end-to-end within the
>>    context of a switched conferencing environment where media
>>    distributors are not trusted with the end-to-end media encryption
>>    keys.  The solution aims to build upon existing security mechanisms
>>    defined for the real-time transport protocol (RTP).
>>
>>
>>  The IETF datatracker status page for this draft is:
>>  https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/
>>
>>  There are also htmlized versions available at:
>>  https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08
>>  https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-08
>>
>>  A diff from the previous version is available at:
>>  https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-08
>>
>>
>>  Please note that it may take a couple of minutes from the time of submission
>>  until the htmlized version and diff are available at tools.ietf.org.
>>
>>  Internet-Drafts are also available by anonymous FTP at:
>>  ftp://ftp.ietf.org/internet-drafts/
>>
>>  _______________________________________________
>>  Perc mailing list
>>  Perc@ietf.org
>>  https://www.ietf.org/mailman/listinfo/perc
>