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

Comments below.

On Fri, Feb 1, 2019 at 11:18 Richard Barnes <rlb@ipv.sx> wrote:

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

[BA] Does this depend on the origin of the JS and how it is delivered?
Development frameworks such as Electron are now quite popular for
delivering native applications. Are you saying that the framework
intrinsically distinguishes a native C/C++ application utilizing the WebRTC
APIs from one partially written in JS?

Seems to me that this Is really about access to media and keys, not
development methodology.

I would also note that DRM frameworks such as EME have their own key
management requirements and definition of “trust” rooted in hardware such
as the TPM.

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

[BA] This is a framework document. As such, it needs to explain the
requirements for key management.

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

[BA] Given that WebRTC APIs are frequently used to develop native
applications, and that existing Web APIs such as EME support handling of
encrypted content, I do not think the above text is adequate. The document
actually needs to articulate the key management requirements.

> 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@ietf.org> 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@ietf.org mailing lists by 2019-02-13. Exceptionally, comments may
>>> be
>>> sent to iesg@ietf.org 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>>
>