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

Martin said:

"This goes against the security architecture..."

[BA]  It's worth noting that the W3C has an existing architecture for transport and playback of encrypted media:

Media Source Extensions (MSE): https://w3c.github.io/media-source/
Encrypted Media Extensions (EME): https://www.w3.org/TR/encrypted-media/

As noted at TPAC, these specifications are already being used for transport of media over alternative transports such as the data channel:
https://docs.google.com/presentation/d/1WOihY0SMJbWvfbc-41GA78F4yzPSwmyDOJ8GbRoU7dw/edit#slide=id.g44b656d873_120_5



________________________________
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Sent: Sunday, November 25, 2018 1:34 PM
To: Eric Rescorla
Cc: Nils Ohlmeier; public-webrtc@w3.org
Subject: Re: Call for adoption - use case for "Trusted application, untrusted intermediary"

On 25/11/2018 22:09, Eric Rescorla wrote:


On Sun, Nov 25, 2018 at 12:45 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com<mailto:sergio.garcia.murillo@gmail.com>> wrote:
On 25/11/2018 21:22, Eric Rescorla wrote:
Rigth, but tunneling is the only mechanism specified in PERC, so I
assume that is the keying mechanism proposed when speaking about
accepting PERC in webrtc., I would not have any issue (in regards of the
keying part) with setting the keys in js either on the app (for trusted
app models) or in the identity server (for untrusted app model).

The problem with this, as Martin indicates, is that this goes directly against the security architecture we have otherwise been using for WebRTC, which involves not having encryption keys handled by the JS or carried directly over the signaling channel.


We are adding a new layer on top of current security architecture, so I fail to see how it invalidates it. As I would fail to see how allowing the js app to encrypt a websocket message would invalidate secure websockets security architecture.

The issue is that this isn't E2E in that security model


Call it app to app (a2a) then.. :)

Jokes aside, trusted app scenario is what most people is asking for in the use cases, and in my opinion there is not so much interest for the untrusted app one. Take into account that without the usage of IdP, you MUST trust the app, and I don't think there are many services in production using it.

Also, going back to the keying topic, the identiy server is trusted by definition, so if the keying/encryption is done within the identity server script, you will have a trusted E2E with an untrusted app.

Best regards

Sergio