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

[Randell Jesup <[e-mail]>]

I've been staying out of this one, but one comment:


On 9/27/2011 7:30 PM, Eric Rescorla wrote:
> 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.


Is there any way we could leverage something similar to CORS to allow
destinations to specify they're willing to take traffic in some manner
other than per-connection ICE?

This could be a lot simpler for PBXes, gateways, and the like to
implement than ICE/SRTP/etc.

The general idea would be to try ICE, and if the other side doesn't
do ICE, check a CORS-equivalent at the same same address on a port
(the port could be specified in DNS SRV records perhaps, or even an
alternate address to use to check).  If it says it's willing to
accept webrtc traffic without verification, great.  (This could be
additionally secured by requiring the server to mark the app/service
as known to be acceptable in the CORS data.)


-- 
Randell Jesup
[e-mail]