> 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 <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. > 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 T. > Bes regards > > Sergio >
Received on Thursday, 29 November 2018 09:45:02 UTC