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 <[e-mail]>]

Hi Bernard,

Thanks for taking a fresh look at this.

On Thu, Jan 31, 2019 at 10:51 PM Bernard Aboba <[e-mail]>
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 <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.
>
>
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 <[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
>>
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc
>