Re: [rtcweb] No a=ice-lite in JSEP-04

[Christer Holmberg <[e-mail]>]

Hi,



Why does the exposure of a WebRTC API determine whether the application must support full ICE or not? Shouldn't it depend on whether the application code is considered "trusted" or not.



For example, assume I would implement a gateway using node.js and WebRTP API. The gateway platform isn't downloading the JavaScript code from a webserver - it is "manually" installed, which means it can be reviewed before it is executed.



Regards,



Christer





________________________________
From: [e-mail] [[e-mail]] on behalf of Justin Uberti [[e-mail]]
Sent: Thursday, 03 October 2013 9:49 PM
To: Harald Alvestrand
Cc: [e-mail]
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Agree with Harald, although I don't like the terms "browser"/"non-browser", since many folks (us included) are making native versions of the WebRTC APIs available, which should conform to the same rules as their web brethren.

WebRTC implementations (basically, anything exposing a WebRTC API) MUST support full ICE, and MUST not support ICE Lite.
WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite.




On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand <[e-mail]<mailto:[e-mail]>> wrote:
On 10/03/2013 06:48 PM, Christer Holmberg wrote:

What I think we DO need to say (eventhough someone may think it's obvious) , in the continous consent spec, is that ICE-lite entities do not send cc STUN requests.

Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one asking for permission (although I may have misremembered something). So this means that if there are no cc STUN requests coming from the ice-lite end, the ice-lite end is neither requesting permission to contine to send, nor is it going to stop sending when the WebRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where it's safe to execute Javascript because there's a limit to how much damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to access that API (for brevity's sake, let's call them "browsers", even though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees we want.

Entities that don't offer an API that allows third parties to start connections from it (for brevity, "non-browsers") have to be taken over in other ways in order to perform an attack anyway, in which case all the WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.






Regards,



Christer



________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] on behalf of Christer Holmberg [[e-mail]<mailto:[e-mail]>]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04


Hi,



Do we really need to say more than the ICE RFC already says? I think it explains when ICE-lite is appropriate, and when it isn't.



Regards,



Christer





________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] on behalf of Matthew Kaufman [[e-mail]<mailto:[e-mail]>]
Sent: Thursday, 03 October 2013 7:01 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <[e-mail]><mailto:[e-mail]> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference.
>
> The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required
anywhere in order to make calls through those gateways. But keeping the
browser from being able to spew media at something that hasn't consented
*is* required.

Matthew Kaufman
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb




--
Surveillance is pervasive. Go Dark.


_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb