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

On Mon, Nov 26, 2018 at 9:53 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> 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."
>

Hmm... Would people be willing to modify this requirement to say that the
JS MUST NOT have e2e keying material?

-Ekr

------------------------------
> *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> 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
>
>
>