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

[Matthew Kaufman <[e-mail]>]

On 9/27/2011 4:20 PM, Roman Shpount wrote:
>
> On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla <[e-mail] 
> <mailto:[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?

No. This is not a correct description of the problem.

ICE isn't about "trusting the site to not do something malicious with 
your media". ICE is about "trusting your browser to not attack other 
devices on your local network or the Internet".

The browser must, without asking the user, be able to prove that the far 
end wishes to receive a stream of media. The standard we have available 
for that is a STUN connectivity check with short-term credentials, using 
a transaction ID that can neither be set from Javascript nor inspected 
from Javascript (to prevent spoofing of the reply). This is basically 
how ICE tests connectivity.

Note that the consent must use the same protocol and port you will be 
sending media on. So for RTP or SRTP over UDP, the consent request must 
be sent and received over that same UDP port.

Matthew Kaufman