Re: Call for adoption - use case for "Trusted application, untrusted intermediary"

This consensus call is ostensibly to adopt the use case in which
trusted applications are able to create media sessions that are
“end-to-end” encrypted in a way that an SFU or other middlebox would
be unable to decrypt them.

On face value, this is reasonable, however, it seems like a very
unreasonable interpretation is being taken. The interpretation taken
in working group discussions is, to be frank, a massive regression in
the security posture of this group.  Most seriously, this is a
perversion of the notion of “end-to-end”. Our interpretation of
“end-to-end” is that the User Agent is the end, not the application.

The consensus of the working group was to adopt the DTLS-SRTP trust
model, in which the signaling application is trusted with identifying
communication peers and maintaining the integrity of session
signaling.  That model does not include granting applications access
to encrypted communications, except where the application is also
explicitly an endpoint.

The requirements identified are:

N26    The application must be able to enable end-to-end payload
confidentiality and integrity protection.

N27    The browser must be able to obtain e2e keying keying material
so as to enable content to be rendered.

N28    TBD: restrictions on the application so as to prevent
unauthorized recording of the session.

An interpretation of N26 as motivation for WebRTC identity or PERC is
far more reasonable and constructive. In fact, PERC was created
specifically to address this problem as stated.  A PERC deployment
with a key distributor that is independent to the media distributor
provides an application (as a key distributor) the means to prevent
the media distributor from accessing media.

We agreed not to permit the use of security descriptions in 2013.
This is circumventing that long-established consensus.

Secondarily, that these capabilities will be difficult to properly use
for anything but the most well-resourced applications is something
that bothers us.  One of the great advantages of WebRTC has been its
ability to make these capabilities more accessible.

Mozilla is opposed to this use case with the proposed interpretation.
Given the existence of solutions with stronger properties, we don’t
believe that the proposed design is useful or necessary.
On Tue, Nov 20, 2018 at 8:00 PM Harald Alvestrand <harald@alvestrand.no> wrote:
>
> From the Lyon summary of actions: “The WG adopts the E2E use case where we trust the application, but not the relay. (to be verified on the list)”
>
>
> The question is whether we should include in our “NV Scenarios” document the scenario currently described in https://w3c.github.io/webrtc-nv-use-cases/#securecommunications* - where the application (Web page) is fully trusted, but uses a relay service that should not be able to decode the transmitted media.
>
>
> The consensus in the meeting in Lyon was that this use case should be included; this call serves to verify that consensus on the list.
>
> Unless objections are raised and verified to be widely held in the discussion, the chairs will assume that the WG has consensus to include this use case.
>
> If you object to this document being adopted, please say so to the list before or on Wednesday, November 28.
>
> Harald, for the chairs
>
>

Received on Friday, 23 November 2018 01:30:55 UTC