W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2018

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

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

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC