Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

[Bernard Aboba <[e-mail]>]

My review of draft-ietf-perc-private-media-framework-08, found below,
represents my personal opinion.

In reading this document, I was disappointed to find that it did not
address some key issues that have been encountered by implementers. I
therefore feel that the document is not ready for publication.

Problem #1:  Definition of a Trusted Endpoint

The document defines a "Trusted Endpoint" as follows:

   Trusted Endpoint: An RTP flow terminating entity that has possession
   of E2E media encryption keys and terminates E2E encryption.  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.


In practice, this definition has created considerable confusion among
implementers, particularly those who have attempted to

implement Web-based applications.


In these situations, an "endpoint" may represent a unitary native
application, or potentially an application written in

Javascript or WASM running on a browser platform.  In such a
situation, portions of the application code may

be provided by multiple parties, which might include the domain in
control of the key management server, a party

unrelated to the provider of the MDD or key management server, etc.
In such situations, the definition of

"trusted endpoint" provided in this document becomes difficult to apply.


This point has been underlined by a recent IESG note sent to the W3C
WEBRTC WG which has been attempting to

develop use cases based upon the PERC framework, and has found itself
unable to come to consensus on the

meaning of a "trusted endpoint":

https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0114.html


In beginning my review of this document, I was hoping to find material
relating to the points made in the IESG

relating to the nature of a "trusted endpoint", but was disappointed
that few of the points made by the IESG

were expounded upon in the document.  Since the IETF generally
requires documents to stand on their own without the

need for IESG interpretation, this appears to represent a serious
inadequacy in the current framework document.

Problem #2:  Relationship to RTP topology model (RFC 7667)


The document defines a Media Distributor (MD) as follows:


   Media Distributor (MD): An RTP middlebox that forwards endpoint media
   content (e.g., voice or video data) unaltered, either a subset or all
   of the flows at any given time, and is never allowed have access to
   E2E encryption keys.  It operates according to the Selective
   Forwarding Middlebox RTP topologies [RFC7667
<https://tools.ietf.org/html/rfc7667>] per the constraints
   defined by the PERC system, which includes, but not limited to,
   having no access to RTP media unencrypted and having limits on what

      RTP header field it can alter.


The Selective Forwarding Middlebox is described in RFC 7667 Section
3.7 as follows:

   Another method for handling media in the RTP mixer is to "project",
   or make available, all potential RTP sources (SSRCs) into a per-
   endpoint, independent RTP session.  The middlebox can select which of
   the potential sources that are currently actively transmitting media
   will be sent to each of the endpoints.  This is similar to the Media-
   Switching Mixer but has some important differences in RTP details...

   As the middlebox selects the source in the
   different RTP sessions that transmit media to the endpoints, each RTP
   stream requires the rewriting of certain RTP header fields when being
   projected from one session into another.  In particular, the sequence

   number needs to be consecutively incremented based on the packet
   actually being transmitted in each RTP session.  Therefore, the RTP
   sequence number offset will change each time a source is turned on in
   an RTP session.  The timestamp (possibly offset) stays the same.

   The RTP sessions can be considered independent, resulting in that the
   SSRC numbers used can also be handled independently.  This simplifies
   the SSRC collision detection and avoidance but requires tools such as
   remapping tables between the RTP sessions.  Using independent RTP
   sessions is not required, as it is possible for the switching
   behavior to also perform with a common SSRC space.  However, in this
   case, collision detection and handling becomes a different problem.
   It is up to the implementation to use a single common SSRC space or
   separate ones.

   Using separate SSRC spaces has some implications.  For example, the
   RTP stream that is being sent by endpoint B to the middlebox (BV1)
   may use an SSRC value of 12345678.  When that RTP stream is sent to
   endpoint F by the middlebox, it can use any SSRC value, e.g.,
   87654321.  As a result, each endpoint may have a different view of
   the application usage of a particular SSRC.  Any RTP-level identity
   information, such as SDES items, also needs to update the SSRC
   referenced, if the included SDES items are intended to be global.
   Thus, the application must not use SSRC as references to RTP streams
   when communicating with other peers directly.  This also affects loop
   detection, which will fail to work as there is no common namespace
   and identities across the different legs in the Communication Session
   on the RTP level.  Instead, this responsibility falls onto higher
   layers.

[BA] I interpret the above text as potentially allowing the MDD to rewrite
the SSRC of

RTP and RTCP packets.  Yet my reading of the framework document is
that such rewriting

could be problematic, since Section 4.3 of the framework document
notes that the SSRC

is utilized to identify which E2E keys are to be used to decrypt a
given RTP media flow:

4.3 <https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08#section-4.3>.
E2E Keys and Endpoint Operations

   Any given RTP media flow is identified by its SSRC, and an endpoint
   might send more than one at a time and change the mix of media flows
   transmitted during the life of a conference.

   Thus, an endpoint MUST maintain a list of SSRCs from received RTP
   flows and each SSRC's associated E2E key information.  An endpoint
   MUST discard old E2E keys no later than when it leaves the conference
   (see Section 4.5.2
<https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08#section-4.5.2>).


[BA] Given the above, it is not clear to me whether the framework document
has added restrictions on

the behavior of the Selective Forwarding Middlebox (such as no SSRC
rewriting), and if so, what the

implications are for existing implementations.



On Wed, Jan 30, 2019 at 7:45 PM The IESG <[e-mail]> wrote:

>
> 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'
>   <draft-ietf-perc-private-media-framework-08.txt> 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
> [e-mail] mailing lists by 2019-02-13. Exceptionally, comments may be
> sent to [e-mail] 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.
>
>
>
>
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc
>