Re: [Iot-onboarding] UX concerns with BRSKI

Ted Lemon <> Sun, 01 September 2019 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDD071200B6 for <>; Sun, 1 Sep 2019 10:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CIMKcFId01aX for <>; Sun, 1 Sep 2019 10:56:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7957212007C for <>; Sun, 1 Sep 2019 10:56:12 -0700 (PDT)
Received: by with SMTP id n7so13317618qtb.6 for <>; Sun, 01 Sep 2019 10:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ( []) by with ESMTPSA id b16sm2280872qtk.65.2019. (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 <>
Mime-Version: 1.0 (1.0)
Date: Sun, 1 Sep 2019 13:56:09 -0400
Message-Id: <>
References: <>
In-Reply-To: <>
To: Michael Richardson <>
X-Mailer: iPhone Mail (17A577)
Archived-At: <>
Subject: Re: [Iot-onboarding] UX concerns with BRSKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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:
> 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 <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> -- 
> Iot-onboarding mailing list