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

On 25/11/2018 22:50, Eric Rescorla wrote:
>
>
> On Sun, Nov 25, 2018 at 1:30 PM Sergio Garcia Murillo 
> <sergio.garcia.murillo@gmail.com 
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
>     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.
>
> We're just relitigating the previously-decided SDES discussion now. 
> There's an important distinction between a situation in which the app 
> is responsible for establishing identity and one in which the traffic 
> key traverses that app directly.
>
No we aren't because it is a completely different scenario. Even if the 
outher keys are compromising by using it in the app, the inner dtls keys 
are not and on worst scenario we would be on same scenario as what we 
are today in webrtc 1.0.


>     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.
>
> I don't understand what you are arguing here.


That the IdP script is trusted, so I don't see any reason why it can't 
handle the keys.