W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2018

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 25 Nov 2018 13:09:56 -0800
Message-ID: <CABcZeBObhDBP7eKsWGo8N+TKORVCK6kWF8N45MLgTkK+LmBG7w@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, public-webrtc@w3.org
On Sun, Nov 25, 2018 at 12:45 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 25/11/2018 21:22, Eric Rescorla wrote:
>
> 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.
>
>
> We are adding a new layer on top of current security architecture, so I
> fail to see how it invalidates it. As I would fail to see how allowing the
> js app to encrypt a websocket message would invalidate secure websockets
> security architecture.
>
The issue is that this isn't E2E in that security model

-Ekr

You may consider it insufficient, but that is a different topic.
>
> Best regards
>
> Sergio
>
Received on Sunday, 25 November 2018 21:10:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC