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