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

On Fri, Nov 23, 2018 at 11:05 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 24/11/2018 6:01, Nils Ohlmeier wrote:
> >
> >> On 23Nov, 2018, at 02:31, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
> >>
> >> Also speaking as a SFU developer, they DTLS tunneling stuff for keying
> is a big no.
> > Why would that be a No?
>
> Mainly, because there are alternatives that requires not to implement
> anything on the SFU and only require framemarking to be implemented.
> This has been validated and it is working on Jitsi, Janus and Medooze
> SFUs. It will add another integration point with an external server,
> which we don't have available for testing, so we will have to mock it up
> and then make tests with each new external key manager that we have to
> deploy with.
>
>
> > It is probably also worth pointing out that the PERC working group has
> not settled yet for that being the only way to establish double encryption
> keys.
>
>
> Rigth, but tunneling is the only mechanism specified in PERC, so I
> assume that is the keying mechanism proposed when speaking about
> accepting PERC in webrtc., I would not have any issue (in regards of the
> keying part) with setting the keys in js either on the app (for trusted
> app models) or in the identity server (for untrusted app model).
>

The problem with this, as Martin indicates, is that this goes directly
against the security architecture we have otherwise been using for WebRTC,
which involves not having encryption keys handled by the JS or carried
directly over the signaling channel.

-Ekr


> Best regards
>
> Sergio
>
>
>