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

On Mon, Nov 26, 2018 at 9:43 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

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

You'll notice that that architecture doesn't involve *capture*.

-Ekr


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