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 IESGwere expounded upon in the document. Since the IETF generally requires documents to stand on their own without theneed 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] 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 sequencenumber 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 ofRTP and RTCP packets. Yet my reading of the framework document is that such rewritingcould be problematic, since Section 4.3 of the framework document notes that the SSRCis 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 onthe behavior of the Selective Forwarding Middlebox (such as no SSRC rewriting), and if so, what theimplications are for existing implementations.
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
