Re: [Iot-onboarding] UX concerns with BRSKI

Eliot Lear <lear@cisco.com> Sun, 01 September 2019 20:39 UTC

Return-Path: <lear@cisco.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 5E08D1200B3 for <iot-onboarding@ietfa.amsl.com>; Sun, 1 Sep 2019 13:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 LxFMo8g818s0 for <iot-onboarding@ietfa.amsl.com>; Sun, 1 Sep 2019 13:39:41 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BF11200B8 for <iot-onboarding@ietf.org>; Sun, 1 Sep 2019 13:39:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70343; q=dns/txt; s=iport; t=1567370381; x=1568579981; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=1V+/WFe6PhnAP2gicy9Lb5SpwscwjYnOJQOzofA7lpI=; b=H2hnVSLt1088NihtGyJelipUDXVcMjVfjYRe92eaYWbvm9tH/IN3wUaw AJes/YPlYTpkrab6OVwbsidHaD7MTBAdTzImwG+19RAoBgKeshawsCPKW 7tZ2c9D2DOqRTp1+wvjBiHv8Hdni5lexazs/bwKAOeNHsta/ItujOdZwA c=;
X-Files: PastedGraphic-1.png, signature.asc : 43643, 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AAAaLGxd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBghdtUyASKoQhiHyHeSWTEIgFAgcBAQE?= =?us-ascii?q?JAQIBASMMAQFVg2oCgwM3Bg4CAwgBAQQBAQECAQYEbYUuDIVKAQEBAQIBBQE?= =?us-ascii?q?dVgULCw4EBgUBAQEiAgICFQEOIw4GEgEGgxwBgXsPD6oTgTKENQGBFIRoCga?= =?us-ascii?q?BNAGBUIo/gX+BOAwTgkw+hCiDJzKCJgSMLwsoF4hPjReJOoIpgieBEYIqjEK?= =?us-ascii?q?CNxuCM4c2ilqEI6Mwgw8CBAYFAhWBZiI3gSEzGggbFTsqAYJBPohMh38+AzA?= =?us-ascii?q?BjRgrgicBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,456,1559520000"; d="asc'?png'150?scan'150,208,217,150";a="16236843"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Sep 2019 20:39:38 +0000
Received: from dhcp-10-61-98-64.cisco.com (dhcp-10-61-98-64.cisco.com [10.61.98.64]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x81KdbVs016374 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Sep 2019 20:39:38 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <D6A63DA9-6675-4D50-8BC7-7AC9060BC2CD@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C447011D-CCD1-42EC-ABAD-288459ADDAB8"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 1 Sep 2019 22:39:37 +0200
In-Reply-To: <18791.1567357694@dooku.sandelman.ca>
Cc: iot-onboarding@ietf.org
To: Michael Richardson <mcr@sandelman.ca>
References: <18791.1567357694@dooku.sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.98.64, dhcp-10-61-98-64.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/9XVtRjCXAeRerAOXgoNLfIiE_TQ>
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 20:39:45 -0000

Thanks Michael and Scott.  Please see below.

> On 1 Sep 2019, at 19:08, Michael Richardson <mcr@sandelman.ca>; wrote:
> 
> Signed PGP part
> 
> 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 <https://www.connections.iiesoc.in/2018-abstract>

In particular note slide 15 and please see below.

> 
> 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.

At the end of the day what I think we’re talking about is, at its highest level:



The form of that signature and the trust anchor to that signature need to be points of flexibility within the architecture.  What’s precisely in the bag, especially with regard to a voucher like 8366 is already flexible.

The other point I would make is that as someone who works at a router company, if we could put all the smarts in the routers, we would.  But if you want to plug the thing in and just have it work, the thing needs to ask someone who can prove which entity it belongs to, and that needs to come either directly or indirectly from the manufacturer.  That doesn’t necessarily mean you need to use BRSKI to do all of that.  Intel’s SDO does something quite similar.

Eliot