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

On Thu, Nov 29, 2018 at 1:44 AM westhawk <thp@westhawk.co.uk> wrote:

>
>
> On 28 Nov 2018, at 16:08, 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.
>
>
> Heh, that’s a mis-feature in my view which I missed when it was discussed.
> It should be possible to request isolated streams any time you are using a
> generated/stored Certificate().
> There are ways the identity of the remote party can be verified without IdP
>

I think I would be OK with allowing isolatedStreams in those cases. I don't
immediately see any problem with that.

-Ekr


> T.
>
> Bes regards
>
> Sergio
>
>
>