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

[Cullen Jennings <[e-mail]>]

On Sep 27, 2011, at 10:50 PM, Randell Jesup wrote:

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

Randell, I have thought about this awhile back and what I come up with is something that has very close to the same messages as ICE. In addition, this new thing would have to be deployed on all the end points - so it would be even hard to get deployed than ICE and I doubt it would end up being any easier - and that just to solve the security problem. You still have to solve the nat  traversal problem and things like transition to v6. So, I'd be happy to talk about ideas on this, but when I drew the "boxes and arrows" diagram for something like CORS for RTP, it did not come out looking any easier than ICE, and in fact it looked awfully close to the "boxes and arrows" for ICE. Give it a try on a napkin and see if you come to the roughly the same conclusion. 


> 
> 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]
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb