Re: [Perc] AD Evaluation of draft-ietf-perc-private-media-framework-07

["Paul E. Jones" <[e-mail]>]

Ben,

I was chasing people down for comment. I got that end of last week, so I hope to get a new draft put later this week or the weekend.

Paul


-------- Original Message --------
From: Ben Campbell <[e-mail]>
Sent: January 14, 2019 6:11:32 PM EST
To: [e-mail]
Cc: [e-mail]
Subject: Re: AD Evaluation of draft-ietf-perc-private-media-framework-07

Hi,

What’s the status of getting an update? It would be nice to get this through IETF LC and the IESG evaluation before Prague.

Thanks!

Ben.

> On Oct 22, 2018, at 2:47 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi,
> 
> This is my AD Evaluation of draft-ietf-perc-private-media-framework-07.
> 
> I appreciate all the work that has gone into this, but I think this draft still needs some work before the IETF last call. I have some substantive and significant editorial comments that I would like to resolve prior to the LC.
> 
> Thanks!
> 
> Ben.
> 
> -------------------------
> 
> Substantive Comments:
> 
> §1, 2nd paragraph: This paragraph needs to tie the ideas together better. It says the ability to deploy in virtual environments is an advantage, but the rest of the paragraph seems to argue why doing so is insecure. I _think_ the idea is to say that this draft helps improve that security, thus helping remove a barrier to taking advantage of virtual/cloud environments? If so, please say so.
> 
> §2: Please use the new boilerplate from RFC 8174. There are multiple uses of lower-case “must” and “should” in the document that don’t appear to be intended as normative.
> 
> §2, definition of MD: It seems like this definition is a little too focused on the PERC trust model, and leaves out the definition of it as a middlebox that forwards the active stream without modification. (I guess that’s caught in the reference to 7667, but it would be better to include the core of the definition here, rather than imply it by reference.
> 
> §3.1.1: "The actual
> media content MUST NOT not be decryptable by a Media Distributor, so
> it is untrusted to have access to the E2E media encryption keys.”
> 
> I’m not sure that MUST NOT should be stated normatively, as it’s really a statement of fact, or at least a foundational assumption.
> 
> §3.1.1, paragraph 3: "A Media Distributor MUST perform its role in properly forwarding
> media packets while taking measures to mitigate the adverse effects
> of denial of service attacks (refer to Section 6), etc, to a level
> equal to or better than traditional conferencing (i.e. non-PERC)
> deployments.”
> 
> That requirement is too vague for a normative MUST. Consider leaving the normative language to section 6.
> 
> §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.
> 
> §4.2, first paragraph: "participants in the conference
> MUST keep track of the E2E keys”
> 
> This seems redundant to similar requirement in 4.3. The requirements in 4.3 are more precise, so I suggest stating this one descriptively.
> 
> §4.3: "prior E2E keys SHOULD be retained”
> 
> I think there’s some disagreement internal to this document, and between this and EKT (and maybe double?). Please see related comment 0n section 4.5.2:
> 
> §4.4: First paragraph: "this framework requires that every packet be authenticated”: Is that a statement of fact that this framework states a normative requirement elsewhere, or is it this intended to be a normative requirement in itself?
> 
> §4.4, 2nd paragraph: "Using hop-by-hop authentication gives the Media Distributor the
> ability to change certain RTP header values.”
> That’s not really a true statement. It’s the lack of E2E authentication that enables that. It seems like the real point is that, since we can’t use E2E authentication, HBH authentication is better than nothing.
> 
> §4.4, 3rd paragraph: "If there is a need to encrypt one or more RTP header extensions hopby-
> hop, ...” : Is that optional?
> 
> §4.4, last paragraph: "Note that when RTP header extensions are encrypted,
> all hops - in the untrusted domain at least - will need to decrypt
> and re-encrypt these encrypted header extensions.”
> 
> I’m confused by this; the document requires distinct keys for each hop. is there an exception for trusted MDs?
> 
> §4.5.1,
> - 2nd to  last paragraph: "Endpoints MAY use the DTLSSRTP
> generated E2E key for transmission or MAY generate a fresh E2E
> key.”: They have to do one or the other, right? That wording allows then to do neither.
> 
> - Last paragraph:  It would be helpful to describe the security associations involved. Do I understand correctly that an endpoint has an SA with the KD, but not the MD?  But peer MDs do have SAs with each other?
> 
> §4.5.2, 3rd paragraph:
> 
> I think there’s some disagreement on the normative keywords for delaying the switch to new keys. I discussed this offline with Richard, and he replied with the following:
> 
>> There's sort of a conflict here.  The crux is here:
>> 
>> """
>>   Since it may take some time for all of the
>>   endpoints in conference to finish re-keying, senders MUST delay a
>>   short period of time before sending media encrypted with the new
>>   master key, but it MUST be prepared to make use of the information
>>   from a new inbound EKT Key immediately.
>> """
>> 
>> The first part talks about media keys, which conflicts with EKT; it should probably be deleted.  The second part is about processing EKT tags, and should be kept.  So we probably end up with something like the following:
>> 
>> """
>>   In order to allow time for all endpoints in the conference to receive the new keys,
>>   the sender should follow the recommendations in Section XXX of [I-D.ietf-perc-srtp-ekt-diet].
>>   On receiving a new EKT Key, endpoints MUST be prepared to decrypt EKT tags using the
>>   new key.  The EKT SPI field can be used to differentiate between tags encrypted with
>>   the old and new keys.
>> """
> 
> §5.2, 2nd paragraph: If the fingerprint is signed, does the entire signaling network still need to be trusted? Also, should the reference to 4474 be 8224?
> 
> §6:  This is written in forward-looking language about how the framework needs to be designed. That design is complete now, what are the considerations for it’s use as designed?
> 
> Also, there are considerations for attacks other than DOS attacks, right?
> 
> §6.2.1: This section seems odd to me.  I understand not trusting the MD to keep communication confidential or to not tamper with it, etc. But if the MD wants to deny service, it can find much easier ways. For example, simply not forwarding packets.
> 
> §A.1: "Assuming the use of Double...”
> Is that optional?
> 
> - "The media distributor doesn’t perform DTLS-SRTP,...”
> 
> The document describes one case where it does (connections between peer MDs)
> 
> §A.3: "To reduce complexity, PERC
> *RECOMMENDS* that endpoints create random SRTP master keys locally to
> be used for E2E encryption.”
> 
> Is RECOMMENDS intended as normative? If not, where is the actual recommendation?
> 
> Editorial Comments:
> 
> - General: I found the draft to have some issues with flow and fragmentation. I expected this draft give a big-picture overview tying together the moving parts of PERC in a way that tells me how they work together.  I was surprised to find that the text that does that was relegated to the appendices, which I usually see reserved for more optional reading. I recommend promoting the appendix text into a non-normative introduction. (If you follow this recommendation, please edit that text for tone; it veers a bit too far on the casual side in places for a standards track RFC.)
> 
> - General: Please be consistent between using “E2E" or "end-to-end” when referring to keys. (Same with HBH and "hop-by-hop")
> 
> - General: Please be consistent in using present vs future tense when describing procedures. Present tense is usually more readable for that sort of thing.
> 
> §1, first paragraph:
> - "Instead, media flows transmitted by
> conference participants are simply forwarded by the Media Distributor
> to each of the other participants, often forwarding only a subset of
> flows based on voice activity detection or other criteria.”
> 
> The sentence seems to switch subjects half way through. Suggest breaking into two sentences, with the second starting with “Media Distributors often forward only a subset..”
> 
> §1, 2nd paragraph: This paragraph needs to tie the ideas together better. It says the ability to deploy in virtual environments is an advantage, but the rest of the paragraph seems to argue why doing so is insecure. I _think_ the idea is to say that this draft helps improve that security, thus helping remove a barrier to taking advantage of virtual/cloud environments? If so, please say so.
> 
> §3.1.1, 2nd paragraph: "An endpoint’s ability to join a conference hosted by a Media
> Distributor MUST NOT alone be interpreted as being authorized to have
> access to the E2E media encryption keys, as the Media Distributor
> does not have the ability to determine whether an endpoint is
> authorized.”
> 
> MUST NOT be interpreted by what? (consider active voice). Also, I’m not sure what it means for "the ability to join a conference" to be authorized. Consider something to the effect of “... to imply that the endpoint is authorized...”
> 
> §4.1, first paragraph: "access of the end-to-
> end key information”
> s/of/to
> 
> §4.2, first paragraph: Please expand “SSRC" on first mention.
> 
> §4.3:
> - 2nd paragraph:"Receiving
> endpoints MUST discard old E2E keys no later than when it leaves the
> conference.”: singular/plural disagreement.
> 
> -3rd paragraph:"an encryption key is derived”: Derived by what? (consider active voice).
> 
> §4.4, section title: should “Hop Operations” be “Per-hop Operations”?
> 
> §4.4, last paragraph: "an encryption key is derived”: derived by what? (consider active voice.)
> 
> §4.5.2, last paragraph: "Endpoints are at liberty to change the E2E encryption key used at any
> time. Endpoints MUST generate a new E2E encryption key whenever it
> receives a new EKT Key.”
> 
> To be consistent with the “MUST" in the 2nd sentence, it seems like “are at liberty to” should be “MAY”.
> 
> §5: “The key requirements is...” : plural disagreement.
> 
> §6.1, 2nd paragraph: "If not
> making use of HBH authentication on the Media Distributor, such an
> attack could only be detected in the receiving endpoints where the
> forged packets would finally be dropped.”
> 
> The sentence suggests that an attack might make use of HBH authentication. I don’t think that’s the intent.
> 
> §6.2.2: Missing article before “Replay”
> 
> Appendix A:
> 
> -- "The time required to retain old keys (either EKT Keys or SRTP master
> keys) is not specified, but they should be retained at least for the
> period of time required to re-key the conference or handle latearriving
> or out-of-order packets. A period of 60s should be
> considered a generous retention period, but endpoints may keep old
> keys on hand until the end of the conference.”
> 
> That should be stated in the main body.
> 
> -- "Or more detailed explanation of each of the keys follows.”
> 
> Sentence fragment.
> 
> Appendix B:
> 
> It really seems like the packet format should go in the main body (if it’s needed in this document at all.)
> 
> Also, is there really anything called a PERC packet? That would be" SRTP with double", or something like that, right?
> 
> 
> 
> 
> 
> 
>