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

Dr. Alex said:

"Bernard, mixer and microsoft position?"

[BA] Microsoft Edge has implemented Encrypted Media Extensions (EME).  There are no current plans to implement PERC.
________________________________
From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Sent: Friday, November 23, 2018 9:47 PM
To: Eric Rescorla; lorenzo@meetecho.com; Emil Ivov; Bernard Aboba
Cc: Sergio Garcia Murillo; <public-webrtc@w3.org>
Subject: Re: Call for adoption - use case for "Trusted application, untrusted intermediary"



On Fri, Nov 23, 2018 at 5:11 PM Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:


On Fri, Nov 23, 2018 at 2:29 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com<mailto: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.

This doesn't seem like an inherent issue with PERC, unless I am missing something.

You're missing the entire discussion at  IETF'99 in pragues where this inherent issue was disclosed, where it was agreed that it was a real issue, and where fluffy proposed "triple" as a way for "double" to go around it. PERC meetings were basically cancelled ever since.

It's not clear to me that it's solved by this proposal.

Well, no perc: no perc problem. Anyway, the original discussion was not RTP only, so PERC would not apply to other transports.


Also speaking as a SFU developer, they DTLS tunneling stuff for keying
is a big no.

This seems like a position that doesn't really have consensus.

Lorenzo, emil, since you are not only two of the main open source SFU leaders, but also standard committee participants, would you like to state (again) your position here?

Bernard, mixer and microsoft position?

-Ekr




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<mailto: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*<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-nv-use-cases%2F%23securecommunications*&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C6ee4c195dac4443e6d0c08d651d04a76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636786352383244970&sdata=jRpMLy1RvHalAF%2F6%2B7DVZUtUNtHcQDHZZEIUslpn9DU%3D&reserved=0> - 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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsg.linkedin.com%2Fagouaillard&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C6ee4c195dac4443e6d0c08d651d04a76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636786352383254987&sdata=OlmToIp9s7OW6FVyc6CJl5cdS5fz24wvkgvo2oCBpSs%3D&reserved=0>

  *