Re: Dealing with isolation state mismatches

On 05/15/2014 04:03 PM, Martin Thomson wrote:
> This response bothers me a lot.  Because it seems like the adversarial
> model we have had since before I was even involved isn't well enough
> understood.

Yep.

Or - the way I describe it - the model that is in your mind isn't 
explicit enough in the documents for me to be sure it's the same model 
as is in my mind.

>
> The model says that user A and user B may or may not trust each other.
>   But they probably trust each other with the media that they choose to
> send.  If they don't trust each other that far, then they probably
> shouldn't be placing calls to each other.
>
> The term user agent is carefully chosen, and totally necessary in
> this.  Users don't know how to flip bits, so they have some software
> do it for them.  That's a browser, and the model suggests that users
> trust their own browsers.  This model also suggests that users that
> trust other users with their media, trust that the other user is using
> a browser that follows the rules too.  So we can basically conflate
> user and browser.
>
> (I think that so far, we're aligned...)
>
> Where the disconnect comes is with parties 5 and 6, or X and Y: the
> origins running javascript in either browser.  In the default case, we
> sort of trust these guys and give them our media.  But the whole point
> of the confidential call case is that we don't.  That's on both sides.
>
> In many cases (and likely all in the near term), X == Y.

For a majority of the point to point cases, I think X == Y is likely.
For all the MCU cases, and for all the gatewaying cases, X =/= Y (Y 
isn't even a browser).

>    That means
> that if you have isolation from X, you had better have isolation from
> Y.  Otherwise you get trivial workarounds.  For example, X has been
> given isolated media.  It creates two RTCPeerConnection instances and
> sends the media to itself, trivially circumventing the isolation.

Nit: It can only do that if it can identify itself as B, which turns 
this into the same kind of threat as any man-in-the-middle attack. But 
yes; if X can choose or spoof the identity, workarounds are trivial.

>
> For this reason, we need a strong signal that media should be
> isolated.  (That's the IETF's business, but I've proposed an ALPN
> mechanism, after feedback from TLS folks that this was probably more
> appropriate than an extension.)  This signal allows a browser to make
> this call.
>
> Now, you claim that a user should be able to do what they want with
> media.  YES.  Definitely.  But that needs to be between the browser
> and the user, not that application running in the browser.

Actually I don't think we're disagreeing that much.

What I gather from this conversation is that isolation of streams makes 
sense for the point to point case (and, most especially, the X == Y 
case). In that use case, signalling of isolation makes sense.

In other cases, it is harder to see how it is useful; it might or might not.

If we document that this is the intended use case for the functionality, 
I'm happy.

>
> On 15 May 2014 02:00, Harald Alvestrand <harald@alvestrand.no> wrote:
>> On 05/15/2014 07:21 AM, Martin Thomson wrote:
>>> This is probably best handled in a room, but here goes.
>>>
>>> A has isolated streams because it thinks it's making a "private" call.
>>>    (Scare quotes intentional.)
>>>
>>> B has regular streams.
>>>
>>> A and B try to establish a call.  Nothing in the signaling they are
>>> using (SDP, woo!) indicates that they are screwed.  The browser runs
>>> the O/A exchange and it seems OK, until the DTLS session blows up.
>>>
>>> Do we want a signal in SDP for this state?  I think that it would be
>>> nice.  We can put a wee attributey thing on the a=identity line.
>>>
>>> Sorry, scratch that, we can request that the RTCWEB working group
>>> consider this as a new requirement on their signaling work.
>>>
>> I'm not sure I quite get the "isolated" property's properties here.
>>
>> When it was initially proposed, I thought it was intended for:
>>
>> A runs a Javascript app X
>> A wants his media to end up only with B, not anyone else X wants to send it
>> to
>> X marks the streams as "isolated", A checks that this is true (oops, UI
>> needed), and is happy
>> X sends the streams to B.
>> B does what B does - records them, mixes them, relays them - whatever. This
>> is OK, because A trusts B with his streams.
>>
>> If we have the "isolation" property be signalled, and honored across the
>> network, it means that there's a trust relationship (or rather, lack of
>> trust) between A and the Javascript running in B's browser - let's call that
>> Y.
>>
>> So the requirement becomes that A wants assurance from Y that it's not
>> peeking at the streams. This also prevents Y from offering functions to B
>> for enhancing, processing, recording or relaying the streams in ways
>> incompatible with isolation - there's a cost to everything.
>>
>> I can't manage to make the logical leap that this is the right thing for all
>> cases.
>>
>> The necessary trust relationship to Y is between B and Y.
>> A negotiation of isolation can only say "Y promises that these streams are
>> isolated, and B can verify that using his browser's UI".
>>
>> So I get at least 3 cases falling out of this:
>>
>> - A doesn't care. No isolation needed.
>>
>> - A doesn't trust X, but trusts B and trusts that B takes care with his
>> streams.
>>    X has to show evidence of isolation. A doesn't care what Y does; he trusts
>> B to verify that,
>>    if needed.
>>
>> - A doesn't trust X, has reasons to distrust Y, but trusts B to verify that
>> Y does the right thing.
>>    X has to show evidence of isolation. Y has to show evidence to X that B
>> should be able to
>>    verify that the streams are isolated.
>>
>> Negotiation is only needed for the third case.
>>
>> If isolation is of value in the second case, it seems that there should be a
>> configuration option in the PC that says "Isolate incoming streams". In
>> general, all means of producing streams should probably offer the option to
>> indicate "these should be isolated" - strictly as a local matter.
>>
>> Is the third case important enough that we really need this in the protocol?
>>
>>
>>
>>
>>

Received on Friday, 16 May 2014 07:17:59 UTC