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

just surfacing things that were said during previous meetings. Don't shoot
the messenger.

- It was explicitly stated during the meeting in lyon that the proposed
scheme was not RTP specific and could apply to other transports. In that
case PERC is not applicable.
- In the case of WebRTC, the underlying UA-controlled DTLS-SRTP mechanism
is still in place.
- In any case, unless the streams are isolated, the application has access
to the media already. That means the application has control over the
media/content, while the UA has control over the transport. The UA can
still ensure that nothing leaves the browser without being protected
on-the-wire, but the application can equally apply any kind of filter to
the media/content before handing it over to the peerconnection, or data
channel, if corresponding API is provided. I believe it to be doable today
for audio already since web audio can pipe in a media track.


On Fri, Nov 23, 2018 at 2:29 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> I would not consider PERC to be a valid solution for WebRTC as it
> requires to reversing the order of RTX/FEC and encryption.
>
> Also speaking as a SFU developer, they DTLS tunneling stuff for keying
> is a big no.
>
> Best regards
> Sergio
>
> On 23/11/2018 2:30, Martin Thomson wrote:
> > 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
> >>
> >>
>
>
>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -