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

On Sun, Nov 25, 2018 at 2:13 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> 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> 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> 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.
>
It's a different scenario but the same reasoning applies: having the JS
(and more importantly, some intermediate server) creates a number of
vectors for passive attack. And because the data is in the clear at the
SFU, then you have the possibility for a completely passive attack. This is
one of the primary reasons why we required DTLS-SRTP and not SDES for basic
WebRTC.



> 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.
>
See above.

-Ekr