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

On 28/11/2018 18:57, Eric Rescorla wrote:
>
>
> On Wed, Nov 28, 2018 at 7:04 AM Sergio Garcia Murillo 
> <sergio.garcia.murillo@gmail.com 
> <mailto: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
>>>     <mailto: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.


Yes, he said it, but I disagree with that statement.

Best regards

Sergio