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: Tue, 27 Nov 2018 15:28:37 -0800
Message-ID: <CABcZeBP8+mDzEh9Yf0mk3JCoLX2Q7LYcPEExkCT9mD+jMK8EOA@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 2:13 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 25/11/2018 22:50, Eric Rescorla wrote:
> 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.
> No we aren't because it is a completely different scenario. Even if the
> outher keys are compromising by using it in the app, the inner dtls keys
> are not and on worst scenario we would be on same scenario as what we are
> today in webrtc 1.0.
It's a different scenario but the same reasoning applies: having the JS
(and more importantly, some intermediate server) creates a number of
vectors for passive attack. And because the data is in the clear at the
SFU, then you have the possibility for a completely passive attack. This is
one of the primary reasons why we required DTLS-SRTP and not SDES for basic

> 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.
> That the IdP script is trusted, so I don't see any reason why it can't
> handle the keys.
See above.

Received on Tuesday, 27 November 2018 23:29:38 UTC

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