Update security and privacy considerations in Discovery

[mmccool]

See here for the labelled issues:

• https://github.com/w3c/wot-discovery/labels/Security
• https://github.com/w3c/wot-discovery/labels/Privacy

Deadline: update of security guidelines for July 2021, possibly WoT Discovery document updates to Security and Privacy considerations section.

[mmccool]

• We have brought up DDoS attacks from complex queries and will add that to the S&PC section of the discovery spec

Other possible S&P considerations:

• Sensitivity of geolocation information (when we have it) for privacy when device is associated with a person, i.e. location of a personal vehicle. This also includes inferred location, e.g. directory estimates location of device based on wifi range
• Sensitivity of directory metadata, e.g. last update (watch, periodic TD updates, time of last update can be used to infer if someone is home...)
• Sensitivity of thing ids (again, when device is associated with a person)
• Query injection (SPARQL and javascript fragments in JSON path) allowing execution of arbitrary code on the server (former is language-sandboxed but DDoS possible; latter needs to have its power limited, e.g. that does not allow arbitrary JS but instead only specific expressions, e.g. string and numeric comparison; regex's are a challenge, need to look at specific features of regexes, e.g. embedded script execution). A JSON path standard that already deals with this would be useful, but... To do: look at Xpath spec to see if these issues are dealt with. One path here is to only allow features in JSON Path that are equivalent to some feature in Xpath, assuming Xpath has already had its power suitably limited
• access control for directories; directories have authentication, maybe some information is limited to certain categories of users; should the standard specify an admin interface to control this?
• Should "nosec" be allowed as a security scheme in some circumstances?

[mmccool]

• Talk about access control first since it impacts many of the other risks. Good access control can mitigate some of the risks.
• Location may be implicit. If a TD simply appears in a directory, then we know the Thing is in range (e.g. of WiFi) so it can register with the TDD
• Sensitivity of client IDs associated with some security schemes. These may be harder to rotate than Thing IDs. Mitigation: hide IDs by treating them as private information (see "uri" examples)
• Mitigations for a lot of these are mitigated by access control. However...
  • This still allows tracking by "authorized" parties, which if you don't own the hardware could be anyone (e.g. the police, a random guy in the IT department of the traffic department, etc).
  • Another option would be to turn off registration; this however just disables discovery
  • Another option encrypt the TD. This still requires some way to identify the TD, which could then be used for tracking by a third party.
  • Move location information to a property of the Thing and don't store in the directory. This however would disable geospatial discovery
  • In general, "disabling" geolocation for personal devices may be necessary, although it still is useful for institutional use cases
  • Another option would be to use a "code generator" to generate IDs (perhaps in combination with encrypted TDs) that is synchronized between the device and another application available to the user. So, for example, a user could use an app on their laptop to generate the current ID and then do a discovery search to find the location of their car, which had registered an encrypted TD with that (rotating) ID with a discovery service.
  • We should study how/if there are any solutions for this in phones, etc.

[mmccool]

• Probably we need to allow "nosec" although it's probably a very bad idea except for development use cases. We could perhaps add an assertion that "If a TDD service is available to anyone other than the developer and supports registration of third-party TDs then it MUST NOT use the "nosec" scheme."
• Some non-nosec options are still insecure so perhaps we should be more specific about good options. We could just refer to the "security best practices" and say "one of the recommended best-practice security schemes should be used"

[mmccool]

Comments (from discovery call):

• Encrypted TDs would not be able to support many features of discovery, including queries (except for retrieving TDs by ID), validation
• We would also have to disable notifications in the directory because when an ID is updated, we want to delete the old TD and create a new one with a new TD. Sending notifications of an update would defeat the purpose.
• A tracker could still watch for deletions followed immediately by creations and "guess" that this is an update (and update their tracker to the new ID). The tracker would have to be the owner of the directory in this case. This however, by itself, just allows the persistent presence of a device to be inferred. However, it might be possible to combine this with other information eg. from DHCP logs (granting IPs to a new device with a known MAC), proxy logs, IP address of registration request to the directory. Similar risk with phones (MAC address), similar mitigations (e.g. rotate MAC address).
• Need to clarify use cases
  • Institutional (factory, smart city) - publishing public services
  • Private (personal use) - services that you want available from remote locations (e.g. access car in parking garage charging station from cafe, e.g. to check status of charge)
• Alternative to encrypted TDs: Private Directories.
  • Register personal devices only to directories that only you have access rights to, e.g. hosted in your personal home gateway

[mmccool]

Kaz mentioned some recent discussion in the DID group on a similar topic, we should look at that.

[mmccool]

Some related issues where we have already raised some of these points:

• Consider using JOSE in Directory service to support object security
• Should security be mandatory on directories for WoT Discovery?

[mmccool]

Useful to review the JSON Path draft from IETF, apparently they addressed some of the security issues in the original (eg limiting the power of legal JS expressions): https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-jsonpath/

[mmccool]

Some confusion between DoS and DDoS that needs to be cleared up. DoS is attacking a service directly to bring it down or deny it to other people (e.g. a Directory service). DDoS is compromising a device and using it to launch DoS attacks on other devices. For Directories a direct DoS attack could take the form of a pathologically expensive query.

[mmccool]

Need to:

• Remove incorrect mention of DDoS (should be DoS)
• Mention DDoS separately. Is an issue for SPARQL Federation.
• Probably should add a section on appropriate access controls and security... use of OAuth2 and scopes should perhaps be highly recommended.
• General guidance: URLs and other introduction mechanisms need to not include extra metadata if unprotected.

[mmccool]

Maybe add note about use of object security in unencrypted networks, e.g. .local domains that can't use normal TLS?

[mmccool]

Going to close since created the new issue w3c/wot-discovery#254 in Discovery repo for this. I could have transferred this issue (the discussion points here are still relevant) but want to consolidate, not create a duplicate.