Re: [Iot-onboarding] UX concerns with BRSKI

Ted Lemon <mellon@fugue.com> Sun, 01 September 2019 17:56 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD071200B6 for <iot-onboarding@ietfa.amsl.com>; Sun, 1 Sep 2019 10:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIMKcFId01aX for <iot-onboarding@ietfa.amsl.com>; Sun, 1 Sep 2019 10:56:12 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7957212007C for <iot-onboarding@ietf.org>; Sun, 1 Sep 2019 10:56:12 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id n7so13317618qtb.6 for <iot-onboarding@ietf.org>; Sun, 01 Sep 2019 10:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1l/29UG2K5gEtU4uKXye+1z0zjX84HzJMWnep2/R91E=; b=J1MHlF3SwfSMeRJv1vJqurjdY89UmFOx3NSJihZX7cUAADF+6o9ig+pqcfpnxPPSjP VTtYnncXWxmCl7HuhAkZSFuFJ5hLchVx4HOPTRHnSMAMPmbaoUhpesjQCKJM2iNDL7wh +CO6IeLM4NZj22Rp29B/P7KclpwDieQs80F2NGUoS4eud6wSad05IusRqiASUGWyCk57 9QWate3+dTHIpt+9nBpxzeYK8ykhtmpKPJZZ/Eb6WHUY+uc+mokBNaTU2FMAP++coN7v 7zNQ+w5FmCotADkgE0m3bqCIg8ItB6WMRqNzpYt2WuWilJqVHCprNsuxd1m0+psuONIw zwHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1l/29UG2K5gEtU4uKXye+1z0zjX84HzJMWnep2/R91E=; b=f6ni78LuAIDGTqkSTMptwi60t3XO+itow7K77mrocKBKxhOD5M9Gu4/aiUL0taoVh9 gKaHuThUz9zZi7r1J0T/jIFUGmukYYmrM1B2ooKlNle5yoNcVd1KB2rDqxekSLQOiir+ ZPyirJHUfm0IYHYqpXQTXCU1BbUCggLaUJDMZ1HnvuYBnEjglBbV50RKOiyfF4YJXgNp Bv6LwUoWRCrc6Ri03UriR6q7VHg8oix3hE6RQuFo1rtwVnI2thwhiQXR3yME48K2qSdb 39sEgSA5hviuBelPusAXIqypD/bas6+RELmMnZEriQbwns6F8yS/6snlDwE6On6Z3+PD 76gQ==
X-Gm-Message-State: APjAAAVWIvV6DdEr2Ax9Slh510o+w1Sm8NSPC4K9zJfFyEuecQscRzVu DT1rIuTXapIBJCingy0VUuwRMzgJeDynlQ==
X-Google-Smtp-Source: APXvYqztBM+D9jHv1n2KhFrkLMkVxLGsfZy1g3OXVMugEhz3l/8z8Yz+TrJE07YwpM7m6JrY0JD7SA==
X-Received: by 2002:ac8:7186:: with SMTP id w6mr12204791qto.371.1567360571210; Sun, 01 Sep 2019 10:56:11 -0700 (PDT)
Received: from [10.0.100.56] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b16sm2280872qtk.65.2019.09.01.10.56.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Sep 2019 10:56:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 1 Sep 2019 13:56:09 -0400
Message-Id: <1FF5E6CC-8829-4282-AD5D-06CD6402307F@fugue.com>
References: <18791.1567357694@dooku.sandelman.ca>
Cc: iot-onboarding@ietf.org
In-Reply-To: <18791.1567357694@dooku.sandelman.ca>
To: Michael Richardson <mcr@sandelman.ca>
X-Mailer: iPhone Mail (17A577)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/45O2M62nC6HF6reGSnab_cSwGrk>
Subject: Re: [Iot-onboarding] UX concerns with BRSKI
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 17:56:16 -0000

Wouldn’t it be simple enough for the devices to just not be responsive until installed?

Sent from my iPhone

> On Sep 1, 2019, at 13:07, Michael Richardson <mcr@sandelman.ca>; wrote:
> 
> 
> Hi, I have been discussing UX issues with BRSKI and various IoT onboarding
> schemes with Scott Jenson of Google's Android IoT team.  He is now on this
> list, and I wanted to share his notions.
> 
> He wrote:
> 
> sj> I'm going to assume that my aspirations line up with ANIMA/BRSKI but not
> sj> completely. My goal is to figure out how to build the following flow:
> 
> sj>   - You install a large number of devices in a location
> sj>   - They power up, auto connect to WiFi (or your favorite wireless transport)
> sj>   - They are validated and secure endpoints are set up
> sj>   - The devices are NOT allowed on the network yet (for Wifi, they could be on a subnet)
> sj>   - Each device points to a schema so it's clear what each wants to do (light, switch etc)
> sj>   - The user is informed of these devices en masse
> sj>   - The user can see who they are from and that they have been validated
> sj>   - With a button push, they are allowed on the network
> sj>   - (further discussion about auto configuring the lights to be controlled by the switches)
> 
> I think that this goal was well within what many others want to do.
> There are some details that need sorting out.
> 
> sj> Thanks for that. Without more market research, it would be foolish to say
> sj> anything too strong but both cases seem likely to have UX problems
> 
> sj>   - Sales channel integration: potentially lots of logistical challenges
> sj>   (e.g. inventory, last minute router changes, etc)
> sj>   - No sales channel integration: 'first one wins' (this one seems the
> sj>   most problematic)
> 
> sj> What I'm trying to solve is the "HomeDepot" use case where you buy your 30
> sj> switches from HomeDepot and it 'just works' when you turn them on.
> sj> Obviously this has no sales channel integration.
> 
> This is indeed a common case.
> And the lack of sales channel integration makes it difficult
> Eliot has a presentation which is linked from:
>     https://www.connections.iiesoc.in/2018-abstract
> 
> sj> You're actually asking quite a bit of the device makers to support BRSKI
> sj> (which I support btw) I wonder if it's time to make the ROUTERS actually
> sj> have some additional smarts.
> 
> I agree that a BRSKI client is additional functionality, and that in some
> cases this is an issue of code space in some devices.  For any device built
> around the Google Android IoT platform (which is an RPI scale device) that's
> just an issue.  The issue if time-to-market, and this is where reference
> libraries come into play.
> I expect to finish a reference client library in RUST this fall, with
> the goal of fitting into RIOT-OS scale platforms.  Whether it wil have DTLS
> or just EDHOC remains to be seen.
> 
> sj> Would it be possible to have these smart
> sj> devices somehow tell the router who they are before they turn on? Here are
> sj> some thoughts:
> 
> sj>   - All devices have an NFC in the packaging
> 
> Many of us have significant problems with NFC. (or BTLE).
> It's just pushing the onboarding problem to a different layer!
> 
> Some years ago (2012!) the conversation we had at one workshop about what
> would happen if someone walked through HomeDepot and collected the NFC from
> all devices.  There was a bit of a gap of onboarding understanding, but
> the attack was what if attacker collects control information on hundreds of
> thousands of lightbulbs... consider if most of the lightbulbs were smart
> bulbs which were purchased by people who didn't have smart lighting systems,
> because cost of making smart lightbulbs was not more than dumb bulbs (after
> marketing and distribution, etc. costs), so the attacker somehow retained
> control over the bulbs.
> 
> {Then attacker turned them *ALL* on at the same time, and then 2 minutes
> later, turned them all off.  Wait five minutes, and turn them back all on and
> off again. Apparently, this can break the electrical grid as turbines turned
> on, and then had nowhere to send the power.}
> 
> So, summary is that I'm skeptical about the NFC solution.
> The security proposes of "near" seem to fail given an equipped attacker.
> 
> sj>   - You tap this on the router. For the next X minutes, any device of that
> sj>   type is captured and an exchange with each device allows this
> sj>   cert/code/etc
> 
> ... or you tap it with your phone, which has an API into the router.
> 
> sj>   - This works for families of devices so you only need to tap 1 of the 30
> sj>   switches you bought
> 
> this is a problem if you have some devices, and your neighbour has some devices.
> It sounds like a nice idea, but without sales channel integration to know
> which of the 29 devices are also on the same sales receipt, it's gonna fail.
> An annoyance, I agree.
> 
> sj>   - There is nothing stopping this from being an app for that router, that
> sj>   way your phone taps the box, not the router
> 
> :-)
> 
> sj>   - Your same exchange with the MASA occurs, this just makes sure the
> sj>   right Router wins
> sj>   - If you're willing to make this only use a phone tied to the router, a
> sj>   QRCode could work as well.
> 
> Yes, I prefer this, and this is the direction WiFi Alliance's DPP has gone.
> 
> sj>   - This implies things could work without internet initially, you just
> sj>   need the router to be powered on
> 
> many would like this.
> 
> sj>   - This same app could show the 'families of devices' that are available
> sj>   and waiting for confirmation. This is a good prompt for what you should be
> sj>   scanning.(or what you've forgotten)
> 
> I think it is reasonable for the router to get a list of devices that are
> trying to connect, and then you can have a list on the phone devices to
> "find".  It's like the egg hunt on Easter Morning.
> 
> sj>   - The only downside is that you might see nearby devices that aren't
> sj>   yours. However with the coming RTT spec in Wifi 802.11az there is a good
> sj>   change to order them so the neighbors are clearly further away.
> 
> That's a good idea, but given that the upstairs apartment can be closer than
> the third bedroom of my apartment, not always going to work.
> 
> sj> What do you think? Is it asking too much to change the routers? I assume
> sj> they have to change already to support the BRSKI protocol. I'm just
> sj> throwing out an NFC reader and/or an app to act as one. (both are more
> sj> expensive clearly)
> 
> APP wins.
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> -- 
> Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding