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

Almost all the arguments in this thread are heavily biased toward the
enterprise model where the application is hosted by a separate entity that
can access the E2E keys, which honestly think this is the same reason the
made PERC so complex that no one adopted it yet! On the other hand there is
a huge demands on having E2EE conference calling for consumer applications
where the application will be host by the same entity, and this is the case
for almost all E2EE messaging services that has web clients. It is up to
the user to trust the service provider of each of them.

Again, this proposal doesn't include any E2EE implementation, it unblocks a
potential use case for app developer to use these APIs to implement their
own E2EE including key exchange, rotation, etc and this is why I didn't
include all of these details in the proposal.

That being said, I still think this is a valid use case, and if you don't
want to recommend it, will keep it as a generic API and developers will use
it anyway!

Emad


On Wed, Nov 28, 2018 at 3:03 PM Richard Barnes <rlb@ipv.sx> wrote:

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