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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 13 May 2019 21:57:10 -0700

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 15 May 2019 02:44:56 +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).

>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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 May 2019 09:11:55 -0400

Thanks, Paul!

Barry

On Tue, May 14, 2019 at 10:45 PM Paul E. Jones <[email-masked]> wrote:
>
> 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 —
> 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
>