Re: Notes on W3C WoT Security Use Cases

And we should include browsers as clients for devices in the home amongst the use cases we look at. I envisage that as home application hubs take off, browsers will evolve to support them. We should coordinate with the W3C Web Platform WG on this.

> On 21 Jul 2017, at 13:09, Mccool, Michael <michael.mccool@intel.com> wrote:
> 
> Anyhow, we can definitely put this on the list of things to consider in the Security TF.  It may be we need to add some metadata to a TD to reflect certificate revocation, for instance (eg whether or not a certain device requires OCSP, etc).   I don’t think we should duplicate information available by other means, though (eg in HTTP headers) or if making that metainformation available just makes it easier for hackers to find vulnerable systems.
> Michael
>  
> From: Mccool, Michael [mailto:michael.mccool@intel.com] 
> Sent: Friday, July 21, 2017 14:01
> To: daisuke.ajitomi@toshiba.co.jp; dsr@w3.org
> Cc: bfrancis@mozilla.com; Soumya-Kanti.Datta@eurecom.fr; Reshetova, Elena <elena.reshetova@intel.com>; public-wot-ig@w3.org; public-wot-wg@w3.org
> Subject: RE: Notes on W3C WoT Security Use Cases
>  
> My point is that if it’s just a nice to have, and only used by developers, then having to install certs manually, or override an error message, or disable revocation checking, is annoying but not fatal.   *Some* IoT applications use browsers for their interface, which is nice, of course.  However, it does not follow that a switch-connected-to-a-light should fail just because the browser interface does. 
>  
> At any rate, it sounds to me that certain recent aggressive revocation-checking behaviors in browsers are causing at least some of the issues brought up (eg using OCSP for every HTTPS connection by default).   For IoT systems going back to a revocation list approach pushed out periodically would make more sense.   Just because a browser does something doesn’t mean it’s a good idea for IoT…
>  
> It would be possible to have a custom app (or even a custom “IoT browser” that can still render HTTP, etc.) that avoids the problem (for instance, by using both OCSP and revocation lists), and maybe with some UI changes (for instance, just providing a subtle warning (eg an icon change) when it can’t check revocation online rather than freaking out).  Standard browsers could also do this as a configurable option if it’s important to support “local” use cases like IoT device interfaces.
>  
> I need to go back through this email thread and see if there were other specific failures cited that are harder to avoid, though.
>  
> In short… it would be nice to break this issue down a bit more into specific technical issues like this (I’m assuming there is more breaking than just revocation checking failing).
>  
> Michael
>  
> From: daisuke.ajitomi@toshiba.co.jp <mailto:daisuke.ajitomi@toshiba.co.jp> [mailto:daisuke.ajitomi@toshiba.co.jp <mailto:daisuke.ajitomi@toshiba.co.jp>] 
> Sent: Thursday, July 20, 2017 14:43
> To: Mccool, Michael <michael.mccool@intel.com <mailto:michael.mccool@intel.com>>; dsr@w3.org <mailto:dsr@w3.org>
> Cc: bfrancis@mozilla.com <mailto:bfrancis@mozilla.com>; Soumya-Kanti.Datta@eurecom.fr <mailto:Soumya-Kanti.Datta@eurecom.fr>; Reshetova, Elena <elena.reshetova@intel.com <mailto:elena.reshetova@intel.com>>;public-wot-ig@w3.org <mailto:public-wot-ig@w3.org>; public-wot-wg@w3.org <mailto:public-wot-wg@w3.org>
> Subject: RE: Notes on W3C WoT Security Use Cases
>  
> Hi Michael,
>  
> > 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?
>  
> That’s my point. Although I don’t know whether it is essential or not, I think this issue is worth working in W3C, in particular, when considering WoT security in W3C.
>  
> Daisuke Ajitomi
>  
> From: Mccool, Michael [mailto:michael.mccool@intel.com <mailto:michael.mccool@intel.com>] 
> Sent: Thursday, July 20, 2017 6:48 PM
> To: Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
> Cc: Benjamin Francis <bfrancis@mozilla.com <mailto:bfrancis@mozilla.com>>; ajitomi daisuke(安次富 大介 ○ＲＤＣ□ＮＳＬ) <daisuke.ajitomi@toshiba.co.jp <mailto:daisuke.ajitomi@toshiba.co.jp>>; Soumya Kanti Datta <Soumya-Kanti.Datta@eurecom.fr <mailto:Soumya-Kanti.Datta@eurecom.fr>>; Reshetova, Elena <elena.reshetova@intel.com <mailto:elena.reshetova@intel.com>>; public-wot-ig <public-wot-ig@w3.org <mailto:public-wot-ig@w3.org>>; public-wot-wg@w3.org <mailto:public-wot-wg@w3.org>
> Subject: 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 <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 <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 <http://www.w3.org/People/Raggett>
> W3C champion for the Web of things & W3C Data Activity Lead

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