Skip to main content

A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)
draft-ietf-perc-private-media-framework-12

Yes

(Alexey Melnikov)
(Ben Campbell)

No Objection

Éric Vyncke
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Suresh Krishnan)

Note: This ballot was opened for revision 09 and is now closed.

Roman Danyliw
(was Discuss) No Objection
Comment (2019-06-05 for -11) Sent for earlier
Thank you for addressing my DISCUSS.

--
(1) Section 1.  Per “Virtualized public cloud environments have been viewed as less secure since resources are not always physically controlled by those who use them and since there are usually several ports open to the public.  This document aims to improve security so as to lower the barrier to taking advantage of those environments”, I stumbled over these sentences.  Improve security relative to what – self hosted environments?  Is the security target have fewer open ports and secure in the face of an adversary with physical access to the system?  The latter seems like a very high bar and the corresponding Security Considerations doesn’t seem to rise to that.

(2) Section 6.1.  “Endpoints have to retain old keys for a period of time to ensure they can properly decrypt late-arriving or out-of-order packets” seems to restate what is stated in 4.5.2 using RFC2119 language.  Here “endpoints have to retain”.  In Section 4.5.2, “endpoints SHOULD retain”.  Which one is correct?

(3) Section 8.1. Per “Off-path attackers could try connecting to different PERC entities and send specifically crafted packets”, could you be more specific on the threat.  Is this something different than any service being exposed on the Internet?

(4) Editorial Nits:
** Section 3. Typo. s/the the/the/
Warren Kumari
No Objection
Comment (2019-05-15 for -10) Not sent
Thanks for a well written, and clear document.
Éric Vyncke
No Objection
Adam Roach Former IESG member
Yes
Yes (2019-05-13 for -10) Sent
I'm glad to see this work finally ready for publication. As I've already
given several rounds of input on this document, I have only minor
editorial comments.
---------------------------------------------------------------------------

§2:

>  This may
>  include embedded user conferencing equipment or browsers on
>  computers, media gateways, MCUs, media recording device and more that
>  are in the trusted domain for a given deployment.

Nit: "...media recording devices, and more..."
                   pluralize _/  \_ add comma


---------------------------------------------------------------------------

§2:

>  In the context of
>  WebRTC...

Please add an informative citation to https://www.w3.org/TR/webrtc/

---------------------------------------------------------------------------


§2:

>  It operates according to the Selective
>  Forwarding Middlebox RTP topologies [RFC7667] per the constraints
>  defined by the PERC system, which includes, but not limited to,

Nit: "...but is not limited to..."

---------------------------------------------------------------------------

§6.1:

Nit: The keys are described in the sections that follow in the order
they are typically acquired, but listed in a different order in Figure 4.
This confused me for several moments. Consider reordering Figure 4 to match
the order in which the keys are described.

---------------------------------------------------------------------------
Alexey Melnikov Former IESG member
Yes
Yes (for -09) Not sent

                            
Alissa Cooper Former IESG member
Yes
Yes (2019-05-16 for -10) Sent for earlier
Glad to see this work progressing.
Ben Campbell Former IESG member
Yes
Yes (for -09) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-05-13 for -10) Sent
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”.
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2019-05-22 for -11) Sent for earlier

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-05-14 for -10) Sent
Thanks for this well-written document.

Regarding the security considerations, I would think that the Key Distributor is actually sometime like a central attack point, however, I don't think that is really discussed in the security considerations section. Would it make sense to add some more words there?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10) Not sent