Comments below.
On Fri, Feb 1, 2019 at 11:18 Richard Barnes <rlb@xxxxxx> 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
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
