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

Barry Leiba via Datatracker <noreply@ietf.org> Tue, 14 May 2019 04:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35A12009C; Mon, 13 May 2019 21:57:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier <nohlmeier@mozilla.com>, perc-chairs@ietf.org, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 21:57:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/hEiQQhlD_Q2IBjFKXEjcej4-a3M>
Subject: [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
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: Tue, 14 May 2019 04:57:10 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-perc-private-media-framework-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a clear document.  Just a bunch of editorial comments here:

In the Abstract, it’s probably past the time to talk about what the solution
*aims* to do, so, “The solution builds upon existing security mechanisms....”

Similarly in the Introduction, “This document defines improved security so as
to lower the barrier....”  (Or just strike the sentence, as the first sentence
of the next paragraph has it covered.)

And the last sentence of the Introduction, “This document defines a framework
for enhanced privacy....”

In Section 2 you define “Trusted Endpoint”, but then also use “Endpoint” and
“endpoint” through the document.  Are these all meant to be the same thing
(that is, all things called “endpoints” here are Trusted Endpoints)?  If so,
please capitalize “Endpoint” consistently, and say “Trusted Endpoint (or simply
Endpoint)” in the definition.

— Section 3.1.1 —

   The key exchange
   mechanisms specified in this framework prevents the Media Distributor

Make it “prevent” to agree with “mechanisms”.

   or better than traditional conferencing (i.e. non-PERC) deployments.

You need a comma after “i.e.”.  Or better still, here and elsewhere in the
document, just eliminate the Latin abbreviation and just say, “traditional
conferencing (non-PERC) deployments.”

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

— Section 4.5.2 —

   Endpoints MUST generate a new E2E encryption key whenever it receives
   a new EKT Key.

Make it “An Endpoint MUST....”

— Section 5 —
I suggest avoiding the phrase “key requirements” to avoid confusion about the
word “key”.  Maybe say “critical requirements” or “important requirements”
instead.

— Section 5.2 —

   Similarly, the Key Distributor's certificate fingerprint
   can be conveyed to endpoint in a manner that can be authenticated

This needs to be one of “an endpoint”, “the endpoint”, or “endpoints”.

— Section 5.3 —
The title should either be “Conference Identification” or “Conference’s
Identification”.

— Section 6.5 —

   Each endpoint generates its own E2E Key (SRTP master key), thus
   distinct per endpoint.

Make it “thus there is a distinct E2E Key per endpoint.”

   Endpoints that receive media from a
   given transmitting endpoint gains knowledge

Make it “gain knowledge”.

— Section 8.2.1 —

   the Media Distributor can attempt to consume the receiving
   endpoints resources.

Make it either “endpoint’s resources” (for one endpoint) or “endpoints’
resources” (for multiple endpoints).

— Section 8.2.3 —

   However, due to fact that the Media Distributor is allowed

Make it “due to the fact that”, or, better, “because”.