Re: [rtcweb] Fwd: Review of security documents

[Martin Thomson <[e-mail]>]

Selective responses inline.

On 5 June 2012 09:50, Eric Rescorla <[e-mail]> wrote:
>> Therefore, it's easy to draw the implicit conclusions of the draft,
>> namely:
>>  1. a receipt consent mechanism like CORS is necessary, and
>>  2. user consent for access to input devices is necessary _and_
>>     sufficient...for this mode.
>
> I've tried to address this some more in Section 4.1.

I like it.

>> PRIVATE COMMUNICATIONS AND CONSENT
>>
>> The above assumes that the site has access to media.  That is,
>> permission for input devices is being granted to the site.  However, it
>> is possible to imagine a mode of communications where the site mediates
>> the creation of a secure channel, but does not have access to that
>> channel.
>
> IMO there are actually two issues here:
>
> (1) consent
> (2) peer authentication
>
> To give an example, I might be happy to have Gmail be able to
> access my camera and microphone without a big consent experience,
> but I still want to be able to have calls that I know Gmail
> can't listen in on in. That way I can have easy calls, but
> when I want security I can have it. I have tried to make this
> clear in the new text.

I think in your situation you want a separate type of consent - access
to a specific "session".  The idea of what a "session" entails
probably needs better definition than this, but I'm sure you know what
I mean.  (I'd probably associate this with a single transport - and
all streams that are attached to that transport, but you don't get to
do that with the current API.  More on that in future, I promise.)

When you consent to granting the site access to input devices, that
site can then record you.  Presumably, the site also gets to record
streams of remote origin without that consent.  What you desire is
something more than just consent to access a device, or peer
authentication...it's a "hands off" signal from the user.

As I've already said, tying the "hands off" signal into peer
authentication is probably a sensible optimization.

>> AUTHENTICATION MODELS
>> [...] The site can offer an identical (or similar) certificate in
>> the DTLS handshake as it did with the HTTPS TLS handshake.
>
> OK. I'll add something to the security-arch document.

Where exactly?

>> CALL MEDIATION AND REPUTATION
> Hmm... my experience is that sites and ad networks don't do
> that much vetting of JS, actually. I've done ad network
> studies where we put arbitrary JS that does a pile of
> XHR-type stuff in ads and nobody seemed to notice.

I've seen a range of responses from sites.  Some sites vet advertisers
carefully, others could care less as long as the money flows.  Those
that vet have usually been stung once already.

If reputation is important to you, then it is your responsibility to
safeguard your own reputation.  If you rely on others, then you can
use technical measures (checking, etc...), or simply rely on their own
desire to safeguard their reputation.

In summary, I don't see a need for a specific technical solution to
this problem.

>> See thread on hiding IP addresses.  In order to avoid tracking via IP,
>> clients should not use the Internet.  I hear that Tor is somewhat handy
>> at making it possible to have cake that you can eat too.  That said, I'm
>> not sure that that particular cake tastes all that nice...
>
> I'm not sure either, but.... what are you looking for he?

Section 5.4 stipulates requirements that I don't think are reasonable.
 Including discussion on the subject, including countermeasures, with
a conclusion that there are no requirements on the API would be good.
However, guidance for site implementers would be sensible.

>> It might make sense to consider _all_ unsecured HTTP is being in the
>> same origin for the purposes of this.
>
> I'm not sure what you are suggesting? Seems like a big error to
> treat http://www.foo.com/ and http://www.bar.com/ as the same
> for consent purposes.

Sorry, that was too abstract to be actionable.

You already established that - in the presence of a network attacker -
consent to foo.com is equivalent to consent to bar.net.  Therefore, it
seems reasonable to regard the two as being equivalent.  Once you make
that leap, then it is easy to see that you don't have enough
granularity to make any consent meaningful.  So you have to conclude
that providing a (persistent) consent for non-HTTPS sites is
pointless.

>> UNLINKABILITY
>>
>> security-arch@S5.5
>>
>> Nothing on this in the security doc.  What is the goal here?
>
> I'm not sure I understand the question. I want to be able
> to make calls to people without having them linked?

What about identity?  While you are in the business of creating an
identity system, wouldn't it be nice if the site you are using
couldn't identify the people using that site?  Imagine that you are
able to create an assertion that you are
[e-mail] (that well known IdP), which is
translated (by the IdP validator) to a [e-mail] only in the
browser chrome...