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

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:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of
> Christer Holmberg [christer.holmberg@ericsson.com]
> *Sent:* Thursday, 03 October 2013 7:30 PM
> *To:* Matthew Kaufman; rtcweb@ietf.org
> *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:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of
> Matthew Kaufman [matthew@matthew.at]
> *Sent:* Thursday, 03 October 2013 7:01 PM
> *To:* rtcweb@ietf.org
> *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 <ibc@aliax.net> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.