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

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

Received on Friday, 23 November 2018 10:28:41 UTC