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

On Wed, Nov 28, 2018 at 7:04 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 28/11/2018 15:45, westhawk wrote:
>
>
> On 28 Nov 2018, at 10:09, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> On 28/11/2018 0:28, Eric Rescorla wrote:
>
> 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.
>
> JS can clone the media stream and just send the media to a rogue server,
> no need to worry about intercepting keys.
>
>
> Isn’t that what isolated streams protect you against ?
>
>
> Indeed, but that requires the usage of IdP, and if IdP is used, we can get
> back to the idea of setting the keys within the same IdP script, so we
> would be on the safe side again.
>
Setting the keys inside the IdP script also breaks the security model -- as
does anything which exposes traffic keys to JS -- as I believe Adam said
already.

-Ekr

Bes regards
>
> Sergio
>

Received on Wednesday, 28 November 2018 17:58:32 UTC