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

EKR said:

" which involves not having encryption keys handled by the JS or carried directly over the signaling channel."

[BA] The use case does not say that encryption keys are accessible to the JS.

N26: "the browser must be able to obtain e2e keying material so as to enable content to be rendered."
________________________________
From: Eric Rescorla <ekr@rtfm.com>
Sent: Sunday, November 25, 2018 12:22 PM
To: Sergio Garcia Murillo
Cc: Nils Ohlmeier; public-webrtc@w3.org
Subject: 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<mailto: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<mailto: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