Subject: [Gen-art] Genart last call review of draft-ietf-perc-private-media-framework-08

From: Linda Dunbar <[email-masked]>
Date: Fri, 08 Feb 2019 16:24:23 -0800

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-perc-private-media-framework-??
Reviewer: Linda Dunbar
Review Date: 2019-02-08
IETF LC End Date: 2019-02-13
IESG Telechat date: Not scheduled for a telechat

Summary:
This document describes a solution framework for ensuring that media
confidentiality and integrity are maintained end-to-end.

Major issues:
 The SRTP Master Key described in Section 6.4 is not listed in the Figure 4 Key
 Inventory. What is the relationship between the KEK listed in the Figure 4 Key
 Inventory and the SRTP Master Key?

Section 6.3 talks about Key distributor sending KEK to endpoints.  Is it via
untrusted network?  how to prevent the KEK from leaking to other points?
 Is KEK same as EKT Key? if yes, why use two names? it is confusing.

Section 5: the first paragraph says that the "Key requirements are that
endpoint can verify it is connected to the correct Key Distributor..", But How?
can you include a reference to the method?

Minor issues:

Nits/editorial comments:
Section 3.2.2: is it a typo? extra "to" in the following sentence?
"...is necessary to for proper conference-to-endpoint mappings."

Best Regards,

Linda

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 16 Feb 2019 04:52:50 +0000

Linda,

Thanks for your feedback.  Please see comments inline.

>  Inventory and the SRTP Master Key?

The SRTP master key is the E2E key in this case. I can see why this is 
confusing. I'll revise the table to add "SRTP master key" in place of 
"Key" on each of the last two entries in Figure 4 and add "E2E" before 
"master key" in section 6.4. I think that should make things clearer.

>  Is KEK same as EKT Key? if yes, why use two names? it is confusing.

The network is untrusted, but the key delivery uses DTLS-SRTP, which 
ensures that the entity delivering the key is trusted (since 
certificates are verified). KEK and EKT Key are the same, yes. That was 
explained in section 4.2. (Personally, I don't like using both terms, 
but I lost that battle long ago. KEK is a more generic term for the 
function/role of the key commonly used in security [e.g., see 
https://csrc.nist.gov/glossary/term/Key_Encryption_Key], whereas EKT Key 
is more specific in defining what the KEK is. This is like saying "I 
drive a car [KEK], specifically a Ford Focus [EKT Key]." That's not the 
best analogy, but I think it explains the difference more clearly than 
just repeating the same words. In PERC, we have only one type of KEK, 
which is the EKT Key. And that was why I was arguing to avoid KEK 
entirely. That said, the counter-argument is that KEK immediately tells 
a security person about the nature of the key.)

>can you include a reference to the method?

PERC is focused on securing the media end-to-end, but the problem of 
properly identifying endpoints or the Key Distributor is a separate 
issue. However, it's absolutely a key requirement to building a secure 
system. Section 5.1 and 5.2 provide two possible approaches to trying to 
tackle that problem, but those are merely options for consideration.

>"...is necessary to for proper conference-to-endpoint mappings."

Yep, definitely another typo.

Thanks!
Paul