Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

[Eric Rescorla <[e-mail]>]

On Tue, Sep 27, 2011 at 4:20 PM, Roman Shpount <[e-mail]> wrote:

>
> On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla <[e-mail]> wrote:
>
>> I'm sorry, but I think you're still missing the point: requiring ICE *is*
>> the security
>> feature.
>>
>>
> I'm sorry, but it I do get the point: ICE is security. My point is, if you
> have a trust relationship with a site, ICE validation can be bypassed, i.e.
> if you trust the application on the site you trust it not to do something
> malicious with your media.  You point is that you do not trust the user with
> the decision to turn off ICE or trust the website, since unlike with all the
> other security decisions this can be used to hurt other people vs. just
> users themselves. So, unless we can invent a robust mechanism to set trust
> agreements with specific web sites, we would be better off forcing ICE for
> everybody. Is this correct description of the problem?
>

I don't know what "trust agreements with specific web sites" means.

The basic situation here is that browser vendors do not want to ship
browsers
which can be used as an attack platform. And since the victim is not the
user
but rather the recipient of the traffic, that's why WebSockets and CORS
require that the server (i.e., the recipient of the traffic) confirm its
willingness
to receive the traffic, as opposed to having the user agree to it. I don't
see
how any trust mechanism that doesn't involve the recipient can have the
right security properties.

-Ekr