Re: Notes on W3C WoT Security Use Cases

I was meaning to bring this up as well.  Michael Koster and I were talking about some related issues yesterday (mDNS, resource directories, etc) and the issue has been brought up by customers who were struggling with keeping devices available when "offline".

I think in the short term mDNS combined with a local resource directory will work, the trouble is, who runs the directory?  OCF will include such a service but it is meant for OCF devices.   We do have a Thing Description registry in our architecture but can't guarantee one will be running in a specific local environment.  Ideally every router would have a local registry/resource directory.   In the shorter term IoT "hubs" may have to provide it (and we may have to deal with multiple registries showing up...).   This could also be part of Edge/Fog computing stacks.

I'm at IETF this week and there is a workshop on Monday on Distributed Internet, and I'm sure distributed DNS is going to be discussed.   In the long term I think these discussions will result in a standard.  What to do in the meantime is the question...

Michael

On Jul 14, 2017, at 17:31, Benjamin Francis <bfrancis@mozilla.com<mailto:bfrancis@mozilla.com>> wrote:

On 14 July 2017 at 16:13, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote:
A fallback could be to use local discovery, e.g. mDNS.  I implemented a mDNS and DHCP client for the Arduino to configure IP networking and to discover the gateway to register the device with.  In addition, note that the work on scripting APIs for the WoT WG includes a discovery API.

Mozilla's gateway implementation currently uses mDNS for initial discovery to bootstrap a secure connection. The gateway is plugged into an Ethernet network and gets an IP address via DHCP which is then broadcast over mDNS using the local domain gateway.local. This local address can then be used to access the first time setup web interface of the gateway (at least on clients which support mDNS, which Android still doesn't. Otherwise the user has to find the local IP address assigned to the gateway). This insecure connection is only used to ask the user to choose their secure subdomain, at which point they are then re-directed to a secure HTTPS connection to configure their username and password.

You can see how this looks to the end user in the Getting Started Guide<https://docs.google.com/presentation/d/1urdIH-0vfXYauEW_gshCNyRzAwjcpSx79N_xXWopffI/pub?start=false&loop=false&delayms=3000>.

We're also exploring other methods of first time setup including using WiFi (the "Chromecast method"), Bluetooth (e.g. Physical Web Bluetooth beacons for discovery and WiFi configuration over Bluetooth), or even audio (which turned out to be very reliable in previous experimental projects).


Of course, you still need to protect against compromised devices on the same local network that either spoof devices or log their activity.

Yes, this is the main problem I was describing. Maintaining a secure connection on the same local network when an Internet connection becomes temporarily unavailable.