[Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-perc-private-media-framework-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/



----------------------------------------------------------------------
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.


----------------------------------------------------------------------
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.