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