Re: [discovery] Adding CORS to NSD API - proposal and issues

Le 3/10/13 16:58 , Rich Tibbett a écrit :
> On Thu, Oct 3, 2013 at 11:11 PM, Jean-Claude Dufourd
> <jean-claude.dufourd@telecom-paristech.fr> wrote:
>> Le 3/10/13 14:51 , Rich Tibbett a écrit :
>>> On Thu, Oct 3, 2013 at 10:04 PM, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr> wrote:
>>>> Le 3/10/13 13:22 , Rich Tibbett a écrit :
>>>>> - For SSDP, a <service> node contained within a UPnP Device Descriptor
>>>>> File must provide a <corsEnabled> sub-element whose value must be set
>>>>> to '1', 'yes', 'y' or 'true'. Otherwise, the <service> is said not to
>>>>> support CORS and is therefore not accessible to web pages (except if
>>>>> the service type is whitelisted by the user or user agent).
>>>>>
>>>> JCD: Does this proposal amount to mandating an NSD-specific extension of SSDP ?
>>>> It sounds like it and if so, no go.
>>>> NSD must fully support legacy SSDP devices/services.
>>>
>>> Please read the full thread and provided references in http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0029.html
>> JCD: Actually, I did the full thread. It is not because I did not chime in that I did not read every single message.
>> I just did not have anything to say until I realized the consequences when reading your proposal.
>>
>>> In case you have done that, would you care to explain your position? Are you speaking on behalf of all device implementers here? (honest question).
>> JCD: If NSD requires modifications to SSDP, it will work with 0 devices at the beginning. This is a sure way to have a standard that will not be used.
>> Note: I had the exact same criticism of Claes' work on making WebIntents work with SSDP by extending SSDP. I am coherent on this subject.
>>
>> NSD has to have a mode which works with existing devices with reasonable usability and reasonable security and most features.
>> Otherwise, I cannot sell it to my prospective customers. It will be impossible to "bootstrap" the NSD ecosystem.
> The proposal includes a contingency for a 'network services whitelist'
> for interacting with existing devices and services. That would be a
> reasonable compromise given the security concerns raised.
>
> This was all discussed on the previous thread.
JCD: As I said before, I did not see the implications until I saw your 
proposal.
And though I read the thread, I had not read your additions to the NSD 
draft about whitelisting.
Your whitelist mechanism makes sense within a single web app active time 
span, but the whitelist I was thinking about (and possibly other people 
too) was a whitelist that would work for consecutive executions of a web 
app.

Whitelist is too general a term. We need to define what is in the 
whitelist, how it gets in and when it gets out.

Your whitelist is tying one web app with some services, a whitelist 
element is added when the user authorizes the discovery of a service by 
a webapp, everything disappears when the web app quits.

I think some people's whitelist only contains legacy services (allowing 
any web app to connect to them), and it is permanent. That is not secure 
enough IMHO

My idea of a whitelist is the same as yours, but there should be a 
choice to make it valid across execution of the same web app.
>
>>>>> - For DNS-SD, a developer must add a 'corsEnabled' key to their DNS-SD
>>>>> SRV record's corresponding DNS TXT record. This key would be
>>>>> case-insensitive in line with the DNS-SD spec itself [2]. Otherwise,
>>>>> the DNS-SD service is said not to support CORS and is therefore not
>>>>> accessible to web pages (except if the service type is whitelisted by
>>>>> the user or user agent).
>>>> JCD: same question for Bonjour...
>>>>
>>>>> - For DIAL, the discovery message response must contain a
>>>>> 'Access-Control-Allow-Origin' HTTP header and the value of this header
>>>>> must be '*'. Otherwise, the DIAL service is said not to support CORS
>>>>> and is therefore not accessible to web pages (except if the DIAL
>>>>> service type is whitelisted by the user or user agent).
>>>>>
>>>>> Each of the above mechanisms is currently a tentative proposal and
>>>>> each warrants further discussion both on this list and in their
>>>>> respective standardization groups.
>>>>>
>>>>> We should also offer an override mechanism for users and/or user
>>>>> agents to create a network services whitelist - enabling access to
>>>>> non-CORS-enabled networked services also. Implementation of such a
>>>>> network services whitelist remains at an implementer's discretion.
>>>>>
>>>>> In case any of the conditions above occur, a network service could be
>>>>> accessed from web pages via the the Network Service Discovery API
>>>>> (subject to all the conditions therein). Web page themselves are not
>>>>> privy to the CORS-detection procedures outlined above since the CORS
>>>>> opt-in process is abstracted away from the API itself to the
>>>>> respective discovery processes.
>>>>>
>>>>> ---
>>>>>
>>>>> Current Proposal Issues:
>>>>>
>>>>> The main problem with this approach is that dissonance has now been
>>>>> introduced between a.) the indicating of support for CORS during the
>>>>> discovery process and b.) _actual_ support for CORS in subsequent
>>>>> service interactions. i.e. If a networked service indicates it
>>>>> supports CORS during the discovery process and then subsequently fails
>>>>> to provide 'Access-Control-Allow-Origin: *' in all subsequent HTTP
>>>>> responses or the networked service doesn't implement the ability to
>>>>> respond to CORS preflight requests correctly (among other potential
>>>>> CORS-related pitfalls) then the process of communicating with a
>>>>> networked service fails and the service is broken for all meaningful
>>>>> purposes (I can't communicate with a discovered process from a web
>>>>> page).
>>>>>
>>>>> One solution to this issue may be to require networked services to
>>>>> opt-in to cross-site requests during their discovery processes (as
>>>>> proposed above) but then for the user agent to 'simulate' CORS support
>>>>> for that networked service's URL endpoint. This is similar to the way
>>>>> the API is currently drafted, by adding service URLs to a URL
>>>>> whitelist that requires the user agent to treat service URLs as if
>>>>> they supported CORS without the service itself needing to support CORS
>>>>> directly.
>>>> JCD: I would apply this method of simulating CORS support on a device whitelist, with the CORS whitelisting being done by the client as part of the security check UI.
>>>> If the user accepts that this web app has the right to discuss with e.g. this UPnP ContentDirectory, then CORS support could be simulated on this legacy ContentDirectory service.
>>>> However, the CORS simulation would need to happen during a later exchange with the service, after discovery, so outside of the scope of NSD, no ?
>>>>
>>> So you are suggesting no change to the specification?
>> JCD: It may seem that my suggestion is to make no change, but actually my suggestion is to go with CORS whitelisting as part of the security check UI, to include the messaging into NSD, and thus, bring the CORS simulation back into scope.
> This proposal gives no reason to implement CORS other than to display
> that CORS is enabled to the user - where the CORS functionality is
> defunct anyway since we can just use URL whitelisting (or 'CORS
> simulation') at all times.
JCD: I am not sure I get your meaning. Yes, there is not incentive to 
implement CORS in those devices because the device will work with NSD 
regardless of whether it implements CORS or not.
But we are talking legacy devices already in your home. These cannot 
"implement CORS", you can only replace them with newer versions, which I 
would like to avoid forcing people to do.

As for incentives for the manufacturers to add CORS to their services 
for future versions, sorry, it is not my problem.


>
> This makes no sense unless I've interpreted your proposal above
> incorrectly. It could, of course, be brilliant and I missed it.
JCD: I am not trying for brilliant. I am trying for a standard that has 
a chance in practice.
I have already designed a standard which I thought was technically 
brilliant and which failed miserably in practice. Not again.

>
>>> Please fully read the background to this thread. I believe the proposed changes are inevitable in light of implementer feedback.
>> JCD: Changes are inevitable.
>> Your proposal would endanger NSD by making its bootstrapping very difficult.
> See 'network services whitelist' discussion above.
JCD: I was talking about your proposal requiring an extension to SSDP, 
not the whitelisting.

>
>> I hope we can find other changes that will not require starting an ecosystem from scratch.
> One proposal you have mentioned elsewhere on this list is to implement
> a structured UPnP Messaging API as a way to mitigate stated security
> risks (http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0030.html).
>
> Let's talk about that briefly since I cannot follow what else is being
> requested in this thread.
JCD: My stated intention is to stop your "SSDP extension" proposal.
Can I be any clearer ?

>
> I don't think a high-level messaging API would solve any security
> issues as cleanly as it would seem. It simply defers problems to a
> different level of the stack. We would need to create a node-based API
> for messaging and implement multiple variations of service messaging
> types - discarding innovation in service types or messaging formats
> for the future. I think there's little appetite to enable or repeat
> more DOM-manipulation-like APIs here. Most vulnerabilities present in
> unstructured HTTP messaging could easily also occur in a structured
> HTTP messaging API. Any API with a large surface area would also
> increase the number of attack vectors available.
JCD: By relying on other technologies to implement the messaging, you 
already
defer the security problem to another level of the "stack".
Yes, creating a messaging API restricts future innovation, including 
innovation in hacking.
You cannot have your cake and eat it too: security comes with 
restrictions, not with
leaving the field wide open to any possible type of communication.

We have implemented and tested such a messaging API, it has ONE method.
So forget about "more DOM-manipulation-like APIs".
Service advertizing: one method and one object class.
Eventing: one methods.
>
> I've written about why a low-level unstructured approach, building on
> top of existing web platform details such as XHR, WebSockets, etc, is
> a good idea for the NSD API in
> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0004.html.
> Also, http://extensiblewebmanifesto.org is a good primer for why we
> want to implement low-level APIs for new features initially. Nothing
> here rules out higher-level APIs down the line but that is not the
> initial objective.
JCD: And as I understand this position from a browser vendor, I insist that
other positions are valid and defensible and possibly also worth some 
interest.
I believe we should stick with *simple* APIs, not necessarily 
*low-level* ones, specially when
interlocking constraints from security, usability and backward 
compatibility create a seemingly
impossible problem.
Best regards
JC

>
>>>>> The new part in this process is that networked services need to opt-in
>>>>> to cross-site requests during discovery (via the mechanisms above)
>>>>> rather than the user agent providing that access for all networked
>>>>> services by default (as per the previously specced approach). That
>>>>> seems to meet the objectives of this exercise without introducing any
>>>>> potential dissonance between the service discovery process and the
>>>>> service communication process.
>>>>>
>>>>> Minor point: If we do agree to go with this idea instead then it may
>>>>> make more sense to rename 'corsEnabled' to 'xsEnabled' in the
>>>>> discovery processes above.
>>>>>
>>>>> So the process essentially becomes CORS-like (where services need to
>>>>> opt-in to cross-site sharing) but the result is 'simulated CORS'
>>>>> (where the user agent acts as if CORS is enabled for URLS belonging to
>>>>> shared networked services).
>>>>>
>>>>> -------
>>>>>
>>>>> Alternative Proposal:
>>>>>
>>>>> During the current drafting an alternative proposal came up and it may
>>>>> be worth mentioning here.
>>>>>
>>>>> Instead of introducing the dissonance discussed above we could instead
>>>>> rely on issuing tentative preflight requests [3] to networked service
>>>>> endpoint URLs once the network service discovery process has been
>>>>> completed as normal (without services needing to opt-in at the
>>>>> discovery stage). This approach has the benefit of actually ensuring
>>>>> CORS is properly supported since we are feature-detecting CORS
>>>>> directly on actual network service URLs rather than trusting a
>>>>> corsEnabled directive during discovery that assues us that CORS is
>>>>> supported on any corresponding network service URLs.
>>>>>
>>>>> ---
>>>>>
>>>>> Alternative Proposal Issues:
>>>>>
>>>>> The major problem with adopting this alternative approach is that the
>>>>> root of a networked service endpoint URL is not always configured to
>>>>> return 200 OK responses (some networked services may provide access
>>>>> only in sub-directories or non-standard root locations which can
>>>>> differ per network service type). CORS preflight requests abort if the
>>>>> HTTP response is not 200 OK, in which case this approach would fail to
>>>>> capture legitimate CORS-enabled networked services during this
>>>>> process.
>>>>>
>>>>> ---
>>>>>
>>>>> So it seems there are a few things we need to think about further here
>>>>> and all feedback is welcome on the best way for us to proceed.
>>>>>
>>>>> br/ Rich
>>>>>
>>>>> ---
>>>>>
>>>>> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0040.html
>>>>>
>>>>> [2] http://tools.ietf.org/html/rfc6763#section-6
>>>>>
>>>>> [3] http://www.w3.org/TR/cors/#preflight-request
>>>>>
> ****
>
> Please use plain-text and proper indentation for W3C mailing list
> discussions. Your current email settings make it difficult/impossible
> to discuss in any reasonably structured way.
>
> see: http://wiki.whatwg.org/wiki/FAQ#Mailing_List and
> http://www.w3.org/2008/webapps/wiki/WorkMode#Mail_List_Policy.2C_Usage.2C_Etiquette.2C_etc.


-- 
Télécom ParisTech <http://www.telecom-paristech.fr>  *Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : +33 1 45 81 77 33  37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter 
<https://twitter.com/TelecomPTech>Facebook 
<https://www.facebook.com/TelecomParisTech>Google+ 
<https://plus.google.com/111525064771175271294>Blog 
<http://jcdufourd.wp.mines-telecom.fr>