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

/me wades in late in the thread...

I don’t think the worlds you guys are envisioning are mutually exclusive.

The invariant to preserve here is: If we a call is made that uses both E2E
and IdP, then it needs to have a security model that’s equivalent to an
IdP-authenticated 1-1 call, where the far end of the call is the
conference.  The E2E keys need to come from some source that is
IdP-authenticated as representing the conference, and they need to not be
accessible to JS.

I’ll grant Sergio’s point that if there’s no IdP, then having the JS
provide the keys for E2E encryption is better than not doing that.  But if
we’re going to create mechanism for that, it needs to be “IdP-compatible”,
in the sense that it needs to scale up smoothly to the security level
described above in cases where IdP is in use.  That requirement is not met
by the current proposal, including the “keys-from-the-IdP” proposal.

It’s worth noting that there’s going to be a need for some EKT-like
mechanism here for distributing E2E keys in any case.  You’re going to need
to avoid nonce reuse, and the easiest way to do that is to have separate
keys per sender.  And of course, you’re going to want to distribute the
sender keys in-band with the media to avoid propagation delays.  So all
we’re really talking about here is how we maintain a KEK for a conference.

As an example of something that seems like it would scale smoothly here,
consider the following architecture:
- The browser negotiates a PeerConnection to a server representing the
conference, and gets a KEK for the conference, (which is not provided to JS)
- JS can then attach this KEK to another PeerConnection (used for media),
which will then apply the E2E encryption and be treated as if it were
authenticated to the conference.

In the case where the first PeerConnection is IdP-enabled, you now have an
IdP-equivalent security level.  If it’s not, then you’re at roughly the
same security level as with the current proposal, but without the risks of
accidental key disclosure that EKR notes.

In any case, the requirements as written in the proposal are hopelessly
vague.   They don’t capture any of the nuance that has come up in this
thread.  So they clearly can’t be adopted as-is.

—Richard

On Wed, Nov 28, 2018 at 1:01 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 28/11/2018 18:57, Eric Rescorla wrote:
>
>
>
> On Wed, Nov 28, 2018 at 7:04 AM Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>> On 28/11/2018 15:45, westhawk wrote:
>>
>>
>> On 28 Nov 2018, at 10:09, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>> On 28/11/2018 0:28, Eric Rescorla wrote:
>>
>> 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
>> WebRTC.
>>
>> JS can clone the media stream and just send the media to a rogue server,
>> no need to worry about intercepting keys.
>>
>>
>> Isn’t that what isolated streams protect you against ?
>>
>>
>> Indeed, but that requires the usage of IdP, and if IdP is used, we can
>> get back to the idea of setting the keys within the same IdP script, so we
>> would be on the safe side again.
>>
> Setting the keys inside the IdP script also breaks the security model --
> as does anything which exposes traffic keys to JS -- as I believe Adam said
> already.
>
>
> Yes, he said it, but I disagree with that statement.
>
> Best regards
>
> Sergio
>
>
>
>