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

[Richard Barnes <rlb@xxxxxx>]

Hi Bernard,

Thanks for taking a fresh look at this.

On Thu, Jan 31, 2019 at 10:51 PM Bernard Aboba <bernard.aboba@xxxxxxxxx> wrote:

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. 

I appreciate that there's confusion here, and I think we can clarify.

It seems pretty clear from the other documents in this suite (draft-ietf-perc-srtp-ekt-diet and draft-ietf-perc-double) that this system only really makes sense in the case where the browser is trusted and the JS is not.  Otherwise, you would not need the DTLS parts of EKT, since you could rely on some external thing to provide the key encryption key.  (Note that this latter architecture was proposed, considered, and rejected by the WG.)

So I would propose we add something like the following to this definition:

"In the context of WebRTC, where control of a session is divided between a _javascript_ application and a browser, the browser acts as the Trusted Endpoint for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP in one-to-one calls)."

 

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

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

Again, the answer is clear here, but the document should be clearer.  The working group discussed SSRC rewriting several times, and concluded that SSRC rewriting could not be allowed in this system.  This decision is reflected, e.g., in the fact that the Double transform does not allow modification of SSRCs.

I'll leave it to Paul to propose concrete fixes here, since I'm less familiar with these points.

--Richard

 

On Wed, Jan 30, 2019 at 7:45 PM The IESG <iesg-secretary@xxxxxxxx> 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
ietf@xxxxxxxx mailing lists by 2019-02-13. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc

_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc