RE: NSD API security

Hi,

I just want to state that Sony supports a CORS-based solution for NSD. We would like the specification to support legacy devices but the user management of white /back list would cause failure.

So basically +1 for Giuseppe's view below.

BR
  Claes

> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 20 september 2013 13:46
> To: Rich Tibbett
> Cc: FABLET Youenn; public-device-apis@w3.org; public-web-and-tv
> Subject: Re: NSD API security
> 
> On Fri, Sep 20, 2013 at 9:28 AM, Rich Tibbett <richt@opera.com> wrote:
> > On Fri, Sep 20, 2013 at 1:18 AM, Giuseppe Pascale
> <giuseppep@opera.com> wrote:
> >> On Thu, Sep 19, 2013 at 11:00 AM, FABLET Youenn
> >> <Youenn.Fablet@crf.canon.fr> wrote:
> 
> > 1. Focus the specification around a CORS-only solution. CORS is an
> > accepted mechanism to allow cross-origin communication on the web and
> > could work well in the local network environment also. The problem
> > with adopting a CORS-only approach is we have zero devices currently
> > ready to step in to this brave new world with us. A specification
> that
> > allows you to connect with precisely zero network services will not
> be
> > useful.
> >
> 
> We can always structure the spec so that:
> - the core spec is designed to only cover opt-in and CORS enabled
> devices
> - and addendum/annex explaining how someone using this solution in an
> environment with a stricter trust model (then the web one) could relax
> some of the constraints
> 
> I know this means 0 services support from day one, but may be easy for
> implementer to allow something like this to start with, and without
> browser support this spec is not going to be useful anyway.
> 
> In short, we should focus our first iteration of the spec in allowing
> communication between apps and services that have been designed with
> this use. In order to do that we need to discuss what extensions would
> be needed to the discovery protocols (and services) to enable this
> 
> 
> > 2. Support whitelisting of specific local network services in the
> user
> > agent, at the user's request to enable communication with those
> > services. Even if we went with a CORS-only approach (see (1.) above),
> > this could be a practical fallback to support existing/legacy network
> > services. This would provide non-CORS-enabled services with the same
> > privileges as CORS-enabled services from the user agent without the
> > service itself needing to support CORS implicitly (as also proposed
> in
> > the current NSD API specification).
> >
> 
> the problem is how this whitelist is built. If you imagine that the
> user is "just" asked "do you want to whitelist x" then is probably not
> too safe. If you imagine a browse menu where people can manually
> whitelist services, that maybe a little bit safer, although a page
> could still try to convince users to go there and enable these services.
> 
> 
> > 3. We could support blacklisting of local network services in the
> user
> > agent ([7]). The current specification currently 'keys' local network
> > service API access on its respective network service type identifier
> > (e.g. 'zeroconf:_boxee-jsonrpc._tcp',
> > 'upnp:urn:schemas-upnp-org:service:ContentDirectory:1', etc). We
> could
> > deliberately disable certain service identifiers from being exposed
> to
> > web pages.
> 
> We should probably start by blacklisting all those services/devices
> that are present high risk of being attached, like routers.
> There is an issue though: some network devices host multiple services.
> Routers for example can also be used as mediaservers.
> Anyway, if we go for the opt-in model, we will only expose
> devices/services that voluntarily ask to be exposed.
> 
> >So if the user agent discovers a service whose type  identifier lives
> >in the network services blacklist, it would never be  offered to a web
> >page, even if that web page was attempting to access  that specific
> >service by its given id.
> >
> > I would prefer a solution that incorporates both (1.)+(2.) above -
> > where we support CORS as the primary mode for communicating with
> > local-networked services but still provide a fallback mechanism that
> > allows users to override that requirement in the user agent - to
> > interact with non-CORS enabled network services.
> >
> 
> Agree but this fallback is probably going to be carefully designed and
> some services should be blacklisted no matter what the user says.
> 
> > Option (3.) has the least impact on the current specification and
> does
> > not require any changes to the respective discovery mechanisms of
> > UPnP, Zeroconf or DIAL (to indicate CORS support). If we are unable
> or
> > unwilling to go with a (1.)+(2.) approach then (3.) seems like a
> > viable shorter-term alternative. We could start creating an initial
> > blacklist of _bad_ local network services today and incorporate that
> > list in to the NSD API spec very quickly.
> >
> 
> We could start by documenteing these risks in the security section of
> the spec.
> 
> 
> > Other proposals would of course be welcome that address the concerns
> > raised in the original threads ([1] [2] [3]).
> >
> >>>
> >>> The discovery part of the NSD API specification seems already in a
> >>> pretty good shape.
> >>>
> >>> The access granting part of the NSD API specification may take more
> >>> time to mature.
> >>>
> >>> Given all of that, would it make sense to split the NSD API
> >>> specification in two documents?
> >>>
> >>
> >> What I personally think it could make sense is to try and define a
> >> "secure" version of the full spec, that "loose" the requirement for
> >> supporting legacy devices and instead assume that discovery
> protocols
> >> and services need to be (slightly) changed to opt-in for this
> feature.
> >> >From there it should be easy to imagine an extension that people
> can
> >> use in other scenarios where they want to support also legacy
> >> protocols and they are able to secure the user home network via some
> >> other means).
> >
> > I think option (1.) + (2.) above could achieve this. If we went with
> a
> > CORS-only approach we would possibly also be able to drop the
> > requirement for user opt-in interfaces on a request-by-request basis
> > (since it would be the local network services themselves that opt-in
> > to the communication in the first place _potentially_ negating the
> > need for users to opt-in also).
> >
> > So, a more secure spec with less user opt-in UI requirements? Yes,
> please.
> >
> 
> not sure this is true. From a security perspective, CORS could help.
> Opt-in though would address the privacy concern. If a device/service
> doesn't want to be exposed to the outside world, it must be able to
> express this desire. Even if CORS may prevent a web page from taking
> with a given device, you have already given out some information e.g.
> that such device is there.
> 
> We have designed the spec in such a way that the information that we
> expose after the discovery phase are limited, but still those
> information could be valuable for "evil" pages.
> 
> >>
> >> BTW assuming we still want to have an api that works across multiple
> >> discovery protocols, this group would have to liaise with the groups
> >> in charge of standardizing such discovery protocols in order to
> agree
> >> on a way for services to opt-in for this API.
> >
> > For HTTP-based discovery mechanisms, it may be sufficient to provide
> > 'Access-Control-Allow-Origin: *' HTTP headers in the network
> discovery
> > messages - those can be interpreted by the user agent to mean that
> > this device/service supports CORS. For DNS-based discovery mechanisms
> > we would need to figure out another way to do this.
> >
> 
> Would this be enough also to epxress the opt-in? in other words, can it
> be that I want to support cors, but I don't want to be exposed to a web
> app?
> 
> > Regardless of the actual solution it would be good if we could get
> > some discussion going in the respective groups around this
> > requirement.
> >
> 
> Agree, let's first update the spec though, so that it's easier to
> explain what we are after.

Received on Thursday, 26 September 2013 13:36:11 UTC