Re: NSD API security

Youenn

Much thanks for bringing this conversation to DAP with the pointers to the various implementation discussions - this is very useful, so thank you.

It seems we have general consensus on CORS support required in new devices but not so much clarity on the tradeoff of enabling legacy devices vs the security issues, and also have some thinking to do regarding Zeroconf.

Even so I'm not quite sure how we can address some of the security concerns, such as the "router and music service combined device" risk. If such a combined device has an implementation flaw enabling an attack, then the music side could be used to take control of the router with severe consequences, but apart from disallowing discovery and use I'm not quite sure which countermeasures Network Service Discovery can offer (regardless of CORS).

The fundamental flaw is that one device has two purposes  allowing flaws from one to affect the other, yet this is also why it is sold and valued - the convenience, cost reduction, lower hardware footprint, easier management etc are also benefits.

We should address the case in the Security Considerations (we should cover the concerns which have been raised repeatedly), but am not quite sure what we should say - do not use dual purpose devices, or MUST NOT allow discovery of such a device (or not support CORS or be whitelisted, effectively keeping it out of scope) or highlight that this is a risk related to data transfer once discovered and that there should be limitations related to buffer overflow attempts etc

We should discuss and add more to the security considerations, if only to highlight various concerns.

Frederick Hirsch
Nokia



On Oct 1, 2013, at 3:09 AM, ext FABLET Youenn wrote:

> Defining a good blacklist/whitelist may not be an easy task.
> Such a list may evolve over time, there is no guarantee that different implementations of the same service type be all safe, a single device may implement both a safe type and an unsafe type...
> 
> Legacy devices can already be accessed by packaged apps and browser extensions without whitelisting.
> Existing services (AV content storage, renderers, printers...) may already be useful to existing packaged apps (music players, image managers...).
> What is missing is the discovery part. This may trigger early NSD API market adoption.
> Enabled features would be translated to web pages once CORS become implemented in devices, using exactly the same code base.
> 
> Early adopters of the NSD API for web apps may resort on browser extensions to access discovered legacy devices, be they HTTP or not.
> Some experiments (https://github.com/youennf/nsdExperiments) showed the feasibility of “bridge” extensions that would either validate-then-send or generate-then-send requests on behalf of a web app (more study needed on security aspects though).
> The web app code adaptation needed to access both CORS-enabled and legacy devices is for instance fairly low.
> Resorting on extensions is probably not that appealing to web developers, but this may still be a viable transition approach.
> 
> A single version of the NSD API should make possible these different approaches.
> Starting from the current specification, that would probably mean removing the whitelisting mechanism.
> Probably also keeping user permission to cover fingerprinting issues.
> 
> Regards,
> 	Youenn
> 
>> -----Original Message-----
>> From: HU, BIN [mailto:bh526r@att.com]
>> Sent: vendredi 27 septembre 2013 00:28
>> To: Rich Tibbett; Dominique Hazael-Massieux
>> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-
>> web-and-tv
>> Subject: RE: NSD API security
>> 
>> At AT&T side, we support Rich and Dom's proposal of supporting both CORS
>> as the primary mode and whitelisting for legacy devices.
>> 
>> While CORS approach will be good for implementers to start with from now
>> on, current legacy devices on market cannot be ignored. If we don't support
>> legacy devices, I am not sure if market eventually will adopt NSD with CORS
>> only approach, or the market will be fragmented.
>> 
>> Thus CORS + whitelisting approach is more reasonable to keep the market
>> support.
>> 
>> Thanks
>> Bin
>> 
>> -----Original Message-----
>> From: Rich Tibbett [mailto:richt@opera.com]
>> Sent: Friday, September 20, 2013 3:44 AM
>> To: Dominique Hazael-Massieux
>> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-
>> web-and-tv
>> Subject: Re: NSD API security
>> 
>> On Fri, Sep 20, 2013 at 6:18 PM, Dominique Hazael-Massieux
>> <dom@w3.org> wrote:
>>> Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit :
>>>> So there are a number of directions we could take this in:
>>>> 
>>>> 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.
>>> 
>>> I think that no matter what, the spec should support a CORS-based
>>> approach.
>> 
>> A CORS approach only? As I said, there are no services I'm aware of that
>> would work with that today so we would also have to see if device vendors
>> are interested in releasing CORS-based devices and services. I know we have
>> a few device vendors on this list so it would be good to hear their opinions at
>> this point.
>> 
>>> 
>>>> 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).
>>> 
>>> I support the idea (at least in theory — it would remain to be seen
>>> whether any user agent would feel confident to support such a
>>> whitelist); but given that this is an exception mechanism, I'm not
>>> even sure it needs to be specified —  since the user agent is
>>> ultimately responsible for managing the same origin policy,
>>> user-specified exceptions to that policy (which such a whitelist would
>>> be) seem beyond what we need to define for interoperability. Or did
>>> you have in mind some specific aspects that would need to be spec-d here?
>> 
>> It may warrant a note in the spec to say that a user agent MAY whitelist non-
>> CORS-enabled network services and that if it does so it MUST pass through
>> XHR/WebSocket messages to the network service endpoints as if they were
>> CORS enabled.
>> 
>> Other than that, I don't anticipate any other issues with interoperability.
>> 
>>> 
>>> Dom
>>> 
>

Received on Thursday, 3 October 2013 01:40:58 UTC