Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2020-10-31
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-09-08
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-07-23
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-06-23
12 (System) RFC Editor state changed to EDIT from MISSREF
2019-08-26
12 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Susan Hares was marked no-response
2019-06-13
12 (System) IANA Action state changed to No IANA Actions from In Progress
2019-06-11
12 (System) RFC Editor state changed to MISSREF
2019-06-11
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-06-11
12 (System) Announcement was received by RFC Editor
2019-06-11
12 (System) IANA Action state changed to In Progress
2019-06-11
12 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-06-11
12 Cindy Morgan IESG has approved the document
2019-06-11
12 Cindy Morgan Closed "Approve" ballot
2019-06-11
12 Cindy Morgan Ballot approval text was generated
2019-06-11
12 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-06-05
12 Paul Jones New version available: draft-ietf-perc-private-media-framework-12.txt
2019-06-05
12 (System) New version approved
2019-06-05
12 (System) Request for posting confirmation emailed to previous authors: Christian Groves , David Benham , Paul Jones
2019-06-05
12 Paul Jones Uploaded new revision
2019-06-05
11 Roman Danyliw
[Ballot comment]
Thank you for addressing my DISCUSS.

--
(1) Section 1.  Per “Virtualized public cloud environments have been viewed as less secure since resources …
[Ballot comment]
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/
2019-06-05
11 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2019-05-22
11 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2019-05-21
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-05-21
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-05-21
11 Paul Jones New version available: draft-ietf-perc-private-media-framework-11.txt
2019-05-21
11 (System) New version approved
2019-05-21
11 (System) Request for posting confirmation emailed to previous authors: Christian Groves , David Benham , Paul Jones
2019-05-21
11 Paul Jones Uploaded new revision
2019-05-16
10 Vincent Roca Request for Telechat review by SECDIR Completed: Ready. Reviewer: Vincent Roca.
2019-05-16
10 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-05-16
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-05-16
10 Alissa Cooper [Ballot comment]
Glad to see this work progressing.
2019-05-16
10 Alissa Cooper Ballot comment text updated for Alissa Cooper
2019-05-15
10 Roman Danyliw
[Ballot discuss]
I support Magnus’s DISCUSS about the need to further discuss the impact of a compromised/rogue end-point.  In addition to the impersonation of others …
[Ballot discuss]
I support Magnus’s DISCUSS about the need to further discuss the impact of a compromised/rogue end-point.  In addition to the impersonation of others in the conference, I am wondering about the impact (perhaps a DoS?) of rogue client flooding the conference with EKT Key updates.
2019-05-15
10 Roman Danyliw
[Ballot comment]
(1) Section 1.  Per “Virtualized public cloud environments have been viewed as less secure since resources are not always physically controlled by those …
[Ballot comment]
(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/
2019-05-15
10 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2019-05-15
10 Warren Kumari [Ballot comment]
Thanks for a well written, and clear document.
2019-05-15
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-05-15
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-05-15
10 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-05-15
10 Alissa Cooper [Ballot comment]
Glad to see this work progressing.

Section 2: Please use the RFC 8174 boilerplate.
2019-05-15
10 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2019-05-14
10 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-05-14
10 Magnus Westerlund
[Ballot discuss]
Its is good to see that this document has continued to improve since I read the early versions. However, there are some one …
[Ballot discuss]
Its is good to see that this document has continued to improve since I read the early versions. However, there are some one issues we do need to discuss if they should be better handled before this document is ready for publication.

A significant security vunerability in PERC that should be made more explicit and is totally missing is the risks with compromised endpoints. Beyond the very evident thing that this endpoint can decrypt all media it receives there are far more sinister risk here. Namely the potential for injection of media that attempts to impersonate another endpoints media stream. Most of SRTP's cipher suits only use symmetric crypto functions, thus enabling anyone with the key to send a packet with any SSRC, and have that being accepted as that source. Where it is has no practical usage in point to point communication, in conferencing it becomes an issue. It allows the usage of media level replay or deep fakes to be used to create media streams that are injected into the media distributors using an SSRC of another endpoint.

The mitiagations that are missing from this document. The fact that a media distributor that is not compromised or collaborating with the compromised endpoint could actually prevent such media injection by applying source filtering of SSRCs and drop all that aren't associated with the endpoint. The other potential mitigation is to introduce another cipher suit that uses a non symmetric integrity protection mechanism, such as TESLA to prevent this type of injection.
2019-05-14
10 Magnus Westerlund
[Ballot comment]
In addition I would appreciate if you really consider these issues, especially A and B.

A. I think the relationship between the media …
[Ballot comment]
In addition I would appreciate if you really consider these issues, especially A and B.

A. I think the relationship between the media distributors and the key distributor needs to be clarified either already in section 3 or in 4. The fact that the key distributor needs to know the full set or their group identity of the media distributors to prevent impostering media distributors. That need is not made clear early enough, only by the end of the security consideration section is is made clear that this is the fact. I think it should be stated explicitly early on.

B. Similar the endpoints relation to the key distributor also needs to be clarified. Also, here diving into potential solutions in Section 5 without making clear why this very fundamental requirement is needed is far from optimal. Also here I think discussion in Section 3 or 4 would be good of their relationship. Especially as this is really relying on mechanism outside of the PERC framework. Thus, such requirements should be very explicit stated and motivated.

C. Section 4.3:

If there is a need to encrypt one or more RTP header extensions end-
  to-end, the endpoint derives an encryption key from the E2E SRTP
  master key to encrypt header extensions as per [RFC6904].  The Media
  Distributor is unable use the information contained in those header
  extensions encrypted with an E2E key.

As RFC 6904 works on type of header extensions, all header extensions of
that type need to be encrypted independent of sender, that could be made clearer.

D. Section 4.5:

  o  The E2E key that an endpoint uses to send SRTP media can either be
      set from DTLS or chosen by the endpoint.
 
  I think "set from DTLS" should be changed to make it clear that the DTLS is with the Key Distributor.

E. Section 4.5.1:

Wouldn't this sentence be clearer:

  Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
  session's media ports for the purposes of key information exchange
  with the Key Distributor.

is worded like this:

  Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
  session with the media distributor and it's media ports for the
  purposes of key information exchange with the Key Distributor.
2019-05-14
10 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-05-14
10 Mirja Kühlewind
[Ballot comment]
Thanks for this well-written document.

Regarding the security considerations, I would think that the Key Distributor is actually sometime like a central attack …
[Ballot comment]
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?
2019-05-14
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-05-13
10 Barry Leiba
[Ballot 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 …
[Ballot 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”.
2019-05-13
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-05-13
10 Adam Roach
[Ballot comment]
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 …
[Ballot comment]
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.

---------------------------------------------------------------------------
2019-05-13
10 Adam Roach Ballot comment text updated for Adam Roach
2019-05-13
10 Adam Roach
[Ballot comment]

Please either move the table in Appendix A to the beginning of Section 1, or add
a forward citation to it from the …
[Ballot comment]

Please either move the table in Appendix A to the beginning of Section 1, or add
a forward citation to it from the introduction. Also, consider adding "SIMD" to
the table.

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

§2.1:

>  o  Middle QP values are normally used in streaming, this is also the
>    range where compression efficiency is important for this
>    scenario.

Nit: "...in streaming. This is also..."

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

§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.
2019-05-13
10 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2019-05-13
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-04-30
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-04-30
10 Paul Jones New version available: draft-ietf-perc-private-media-framework-10.txt
2019-04-30
10 (System) New version approved
2019-04-30
10 (System) Request for posting confirmation emailed to previous authors: Christian Groves , David Benham , Paul Jones
2019-04-30
10 Paul Jones Uploaded new revision
2019-04-25
09 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-04-25
09 Alexey Melnikov Placed on agenda for telechat - 2019-05-16
2019-04-25
09 Alexey Melnikov Ballot writeup was changed
2019-03-27
09 Cindy Morgan Shepherding AD changed to Alexey Melnikov
2019-03-05
09 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-03-04
09 Linda Dunbar Request for Telechat review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-02-28
09 Ben Campbell Removed from agenda for telechat
2019-02-28
09 Jean Mahoney Request for Telechat review by GENART is assigned to Linda Dunbar
2019-02-28
09 Jean Mahoney Request for Telechat review by GENART is assigned to Linda Dunbar
2019-02-27
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Vincent Roca
2019-02-27
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Vincent Roca
2019-02-22
09 Cindy Morgan Placed on agenda for telechat - 2019-03-07
2019-02-22
09 Ben Campbell IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2019-02-22
09 Ben Campbell Ballot has been issued
2019-02-22
09 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2019-02-22
09 Ben Campbell Created "Approve" ballot
2019-02-22
09 Ben Campbell Ballot writeup was changed
2019-02-22
09 Ben Campbell Ballot writeup was changed
2019-02-22
09 Ben Campbell Ballot approval text was generated
2019-02-19
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-02-19
09 Paul Jones New version available: draft-ietf-perc-private-media-framework-09.txt
2019-02-19
09 (System) New version approved
2019-02-19
09 (System) Request for posting confirmation emailed to previous authors: Christian Groves , David Benham , Paul Jones
2019-02-19
09 Paul Jones Uploaded new revision
2019-02-14
08 Vincent Roca Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Vincent Roca. Sent review to list.
2019-02-13
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2019-02-12
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-02-12
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-perc-private-media-framework-08, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-perc-private-media-framework-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-08
08 Linda Dunbar Request for Last Call review by GENART Completed: Not Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-02-05
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-02-05
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-02-04
08 Gorry Fairhurst Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Gorry Fairhurst. Sent review to list.
2019-02-01
08 Magnus Westerlund Request for Last Call review by TSVART is assigned to Gorry Fairhurst
2019-02-01
08 Magnus Westerlund Request for Last Call review by TSVART is assigned to Gorry Fairhurst
2019-01-31
08 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2019-01-31
08 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2019-01-31
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Vincent Roca
2019-01-31
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Vincent Roca
2019-01-30
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-01-30
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-02-13):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, Nils Ohlmeier , perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org, …
The following Last Call announcement was sent out (ends 2019-02-13):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, Nils Ohlmeier , perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org, nohlmeier@mozilla.com, perc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard


The IESG has received a request from the Privacy Enhanced RTP Conferencing
WG (perc) to consider the following document: - 'A Solution Framework for
Private Media in Privacy Enhanced RTP
  Conferencing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a solution framework for ensuring that media
  confidentiality and integrity are maintained end-to-end within the
  context of a switched conferencing environment where media
  distributors are not trusted with the end-to-end media encryption
  keys.  The solution aims to build upon existing security mechanisms
  defined for the real-time transport protocol (RTP).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-01-30
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-01-30
08 Ben Campbell Last call was requested
2019-01-30
08 Ben Campbell IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-01-30
08 Ben Campbell Last call announcement was generated
2019-01-30
08 Ben Campbell Ballot writeup was changed
2019-01-30
08 Ben Campbell Ballot approval text was generated
2019-01-23
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-01-23
08 Paul Jones New version available: draft-ietf-perc-private-media-framework-08.txt
2019-01-23
08 (System) New version approved
2019-01-23
08 (System) Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, David Benham , Christian Groves , Paul Jones
2019-01-23
08 Paul Jones Uploaded new revision
2018-10-22
07 Ben Campbell
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 …
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.
-------------------------

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?
2018-10-22
07 Ben Campbell IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-10-22
07 Ben Campbell IESG state changed to AD Evaluation from Publication Requested
2018-09-20
07 Nils Ohlmeier
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-private-media-framework is targeted at the Standards track,
and this write­up is for Proposed Standard. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document describes a framework for enabling end-to-end encrypted
switched conferencing where the media distributor is not trusted to
decrypt and encrypt the media.

Working Group Summary

The document defines the over arching framework for the Privacy Enhanced
RTP Conferencing WG. It has been extensively discussed in the begining of
the WG, but has been stable now for a long time.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Since the IETF 102 hackathon a branch of Firefox exists which implements
the double encryption as per this framework document. libsrtp, a widely
used SRTP library, has Pull Requests has patches in Pull Requests waiting
to be merged. Cisco and Mozilla have both signaled desire to ship
implementations based on this document.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Nils Ohlmeier; the responsible Area Director
is Ben Campbell.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed a few times. The design team at the
begining on the WG influenced core parts of the document. The shepherd
has reviewed the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I don't have any conerns about the review state of the document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I'm not aware of any conerns at this point in time.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes all three listed author have confirmed via email the the shepherd.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR has been filed against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

It is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not for this document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Reference to RFC 4474 might need to be updated to RFC 8224.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document doesn't need any formal reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

This document references normatively draft-ietf-perc-dtls-tunnel which
is not yet ready to for advancement. The PERC WG will work on this
after moving the initial three documents forward.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This documents IANA section is empty.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.

2018-09-20
07 Nils Ohlmeier Responsible AD changed to Ben Campbell
2018-09-20
07 Nils Ohlmeier IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-09-20
07 Nils Ohlmeier IESG state changed to Publication Requested
2018-09-20
07 Nils Ohlmeier IESG process started in state Publication Requested
2018-09-20
07 Nils Ohlmeier Changed consensus to Yes from Unknown
2018-09-20
07 Nils Ohlmeier Intended Status changed to Proposed Standard from None
2018-09-20
07 Nils Ohlmeier Changed document writeup
2018-09-03
07 Paul Jones New version available: draft-ietf-perc-private-media-framework-07.txt
2018-09-03
07 (System) New version approved
2018-09-03
07 (System) Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, David Benham , Christian Groves , Paul Jones
2018-09-03
07 Paul Jones Uploaded new revision
2018-03-18
06 Suhas Nandakumar Notification list changed to Nils Ohlmeier <nohlmeier@mozilla.com>
2018-03-18
06 Suhas Nandakumar Document shepherd changed to Nils Ohlmeier
2018-03-18
06 Suhas Nandakumar IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2018-03-05
06 Paul Jones New version available: draft-ietf-perc-private-media-framework-06.txt
2018-03-05
06 (System) New version approved
2018-03-05
06 (System) Request for posting confirmation emailed to previous authors: David Benham , Christian Groves , Paul Jones
2018-03-05
06 Paul Jones Uploaded new revision
2017-10-30
05 Paul Jones New version available: draft-ietf-perc-private-media-framework-05.txt
2017-10-30
05 (System) New version approved
2017-10-30
05 (System) Request for posting confirmation emailed to previous authors: David Benham , Christian Groves , Paul Jones
2017-10-30
05 Paul Jones Uploaded new revision
2017-07-03
04 Paul Jones New version available: draft-ietf-perc-private-media-framework-04.txt
2017-07-03
04 (System) New version approved
2017-07-03
04 (System) Request for posting confirmation emailed to previous authors: David Benham , Christian Groves , Paul Jones
2017-07-03
04 Paul Jones Uploaded new revision
2017-03-13
03 Paul Jones New version available: draft-ietf-perc-private-media-framework-03.txt
2017-03-13
03 (System) New version approved
2017-03-13
03 (System) Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, David Benham , Christian Groves , Paul Jones
2017-03-13
03 Paul Jones Uploaded new revision
2016-10-31
02 David Benham New version available: draft-ietf-perc-private-media-framework-02.txt
2016-10-31
02 (System) New version approved
2016-10-31
01 (System) Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, "David Benham" , "Paul Jones" , "Christian Groves"
2016-10-31
01 David Benham Uploaded new revision
2016-07-08
01 Paul Jones New version available: draft-ietf-perc-private-media-framework-01.txt
2016-05-13
00 Suhas Nandakumar This document now replaces draft-jones-perc-private-media-framework instead of None
2016-05-13
00 Paul Jones New version available: draft-ietf-perc-private-media-framework-00.txt