Re: Notes on W3C WoT Security Use Cases

Yep, mDNS/DNS-SD has holes for sure.   It's well known that devices can spoof other devices using it.  But it's (reasonably) widely implemented, so it's a start, and possibly can be used to bootstrap something better.  However, discovery is probably not the main problem if it is only needed during setup (when I assume an external network connection will generally be available, which allows discovery to be made secure by other means).

Regarding the "offline trust" issue, I was looking around for some other discussions and came across the following:
https://community.letsencrypt.org/t/certificates-for-hosts-on-private-networks/174/33
which talks about this scenario.   Most of the discussion is from 2015, though.

It seems to me that if you can install private certificates (during some kind of secure onboarding process, yet another discussion) and configure your system not to insist on checking for revocation every time a certificate is used, and if you are careful about managing renewals (doing so well before they expire...), etc. then it should be possible to get this to work.

Browsers may complain about unknown certs though, which may scare some users, so the question is: is direct access to the devices by a standard browser by an ordinary user (as opposed to a developer, which could just install the private certs) a nice-to-have, or essential?   It may be necessary to install a custom app (which can provision certs using a custom onboarding mechanism) rather than use an ordinary browser to talk to devices.

I also found another RFC discussing Zeroconf security but it was from 2000 and is probably defunct:
https://tools.ietf.org/html/draft-williams-zeroconf-security-00

Michael

On Jul 20, 2017, at 17:54, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote:


On 20 Jul 2017, at 09:09, Mccool, Michael <michael.mccool@intel.com<mailto:michael.mccool@intel.com>> wrote:

A few more points:
1. Zeroconf already supports DNS-SD.
2. DNSSEC may provide a way to bootstrap trust in a local registry (although I have to look into the details of how it would work "locally").
Not saying this is the answer, just putting it on the table so we can argue about it…


Last year I experimented with gateway discovery using DHCP and DNS-SD over mDNS for the Arduino plus Ethernet shield. The device boots up, initialises the Ethernet shield, then uses DHCP to acquire an IP address and then multicast DNS to discover the gateway.  I then reconfigure the Ethernet shield for an TCP/IP connection to the gateway which is then used for asynchronous message exchange.

An attacker could interfere with faked MAC addresses, the DHCP exchange, the spoofing of IP addresses via ARP, and the mDNS/DNS-SD exchange. This suggests the need for mutual authentication when the device registers with the gateway, and a means to back off and look again for the real gateway. The ease with which you can set MAC addresses gives attackers the chance to inject packets into a stream.  This is challenging for the boot strapping process, and requires a recovery mechanism when a stream is tampered with.

My experiments made me eager to tap the knowledge of experienced security experts ...

Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> http://www.w3.org/People/Raggett
W3C champion for the Web of things & W3C Data Activity Lead