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:50:02 -0800
Message-ID: <CABcZeBPR_Qyo6rEw0tHrbLJiCH8pQ94M-x6Y2RcaoYqaBE3JoA@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 1:30 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 25/11/2018 22:09, Eric Rescorla wrote:
> 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
> Call it app to app (a2a) then.. :)
> Jokes aside, trusted app scenario is what most people is asking for in the
> use cases, and in my opinion there is not so much interest for the
> untrusted app one. Take into account that without the usage of IdP, you
> MUST trust the app, and I don't think there are many services in production
> using it.
We're just relitigating the previously-decided SDES discussion now. There's
an important distinction between a situation in which the app is
responsible for establishing identity and one in which the traffic key
traverses that app directly.

Also, going back to the keying topic, the identiy server is trusted by
> definition, so if the keying/encryption is done within the identity server
> script, you will have a trusted E2E with an untrusted app.
I don't understand what you are arguing here.


Best regards
> Sergio
Received on Sunday, 25 November 2018 21:51:02 UTC

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