Re: Call for adoption - use case for "Trusted application, untrusted intermediary" from westhawk on 2018-11-28 (public-webrtc@w3.org from November 2018)

From: westhawk <thp@westhawk.co.uk>
Date: Wed, 28 Nov 2018 15:45:12 +0100
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Nils Ohlmeier <nohlmeier@mozilla.com>, public-webrtc@w3.org
Message-Id: <C5B1D5DF-02A6-4A69-9CD0-D2B5FAE51AA4@westhawk.co.uk>

> 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 ?

> Best regards
> 
> Sergio
>

Received on Wednesday, 28 November 2018 14:45:38 UTC