Re: Dealing with isolation state mismatches

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.

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

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.

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 Thursday, 15 May 2014 14:03:44 UTC