On Wed, Nov 28, 2018 at 7:04 AM 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. > 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. -Ekr Bes regards > > Sergio >Received on Wednesday, 28 November 2018 17:58:32 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC