[Anima] Re: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local Domains

Toerless Eckert <tte@cs.fau.de> Tue, 10 September 2024 16:10 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52302C14F681; Tue, 10 Sep 2024 09:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpQ8a0BNbx_y; Tue, 10 Sep 2024 09:10:53 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D6CC14F619; Tue, 10 Sep 2024 09:10:51 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4X37wS422bz1R6CT; Tue, 10 Sep 2024 18:10:48 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4X37wS3MchzkxG5; Tue, 10 Sep 2024 18:10:48 +0200 (CEST)
Date: Tue, 10 Sep 2024 18:10:48 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Dan Wing <danwing@gmail.com>
Message-ID: <ZuBviIVAlXUpgJNh@faui48e.informatik.uni-erlangen.de>
References: <6FCA933A-F329-4B45-9C72-32FFCAD289BE@gmail.com> <CACJ6M16MgxzE+8Yiebd9hbYC_tY2tt0Sroc4_izOnP3kO3e5fQ@mail.gmail.com> <MW4PR15MB437956E8735320FFE83037C7B3952@MW4PR15MB4379.namprd15.prod.outlook.com> <ZtpGfh15m58gId0Z@faui48e.informatik.uni-erlangen.de> <21866.1725908702@obiwan.sandelman.ca> <3B84302E-11BC-4695-9C31-9179AD32FDB3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3B84302E-11BC-4695-9C31-9179AD32FDB3@gmail.com>
Message-ID-Hash: DG3KBNDGR5XXKFR4MDKACIEAT2FUHLIB
X-Message-ID-Hash: DG3KBNDGR5XXKFR4MDKACIEAT2FUHLIB
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "add@ietf.org" <add@ietf.org>, anima@ietf.org, iotops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local Domains
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/9Ma0RQrPwO4ubHEqiOzYoHfHxQA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

On Mon, Sep 09, 2024 at 04:25:40PM -0700, Dan Wing wrote:
> Adopting the technique from Matter, we might also consider suggesting vendors allow QR codes (or some similar fanciful way) to establish a shared secret or public key for more secure bootstrapping than TOFU.  For guests and even family members, this could be similar to the QR code containing the guest network's SSID and password that is taped onto the refrigerator for parties; this new QR code could also be used to bootstrap that network's Certification Authority for that network's client devices.

We're getting a bit off-topic for add (i think, not sure), but hope this is well in-scope for
anima/iotops:

I think there is still a lot of exploration and experience gaining needed to come to
terms with the most easily deployed security mechanism for home and industrial large-scale
IoT device bootstrap. QR codes can be a great tool, but my personal experience has
rather been mixed:

In the home automation IoT device vendor that had the largest market share in germany, you
could bootstrap devices 
a) via QR code. I did that. So i had to use permanent marker to put some device name onto
   each of my 50 devices as well as the same device name on the fitting QR code piece of paper.
   and scan / stash-away those QR code. Over the past few years i had some incidents where i
   had to re-bootstrap some of the devices. It's grizzly to think about what happens if my
   home controller would fail and whether or not a full backup will actually allow me to
   restore all existing device associations.
b) Via the network to the vendors "trusted" servers. Which where known in the past to be
   often offline during weekends. Because its not a large company and employees there tend
   not to work during the weekend. Unlike people who do their at-home installation.
   Besides that, the security applied with this option is IMHO highly questionable, but luckily
   its proprietary, so nobody really knows for sure. But i think i'm a good guesser.

The experience with a big vendor in the USA of similar equiment and the QR codes there is
similarily hilarious

a) The vendor managed to put the QR codes ONLY onto their devices. Such as in-wall light switches.
So, i simply have to shut off my mains power to remove such a light switch from the wall would
it ever need to be re-bootstrapped.
b) During bootstrap for magical reasons, the mesh network connectivity (z-wave in this case)
seems more picky as during operations. So i can actually not enroll some of the devices from
their target deployment location. And/or have to take my RPI4 controller with me, plug it into
a nearby wall-socket to enroll such a device. (For the QR-code free bootstrap option).

So, all-in-all i think i would try to stay away from QR codes whenever i can, home or 
industrial - but to make that work, the whole network based solutions need a lot more detail
improvement work.

Theoretically i think NFC would be a great option, but i have no actual experience. But the
idea of having a box of 50 devices, and the reseller just has to type a button on the smartphone
to register all 50 devices' NFC tags - that just sounds like an intriguing option. Would also
have solved my QR code experiences. But not sure if it would be cheap enough for typical
home automatin IOT devices. 

Cheers
    Toerless
   
> -d
> 
> 
> > Would you like to be able to shush your multi-room surround-sound music
> > so that you can hear: the door bell, the coffee is ready, or the oven has
> > preheated, waiting for the next tray of ordeuves?
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> > 
> > 
> > 
> > 
> > -- 
> > Add mailing list -- add@ietf.org
> > To unsubscribe send an email to add-leave@ietf.org
> 

-- 
---
tte@cs.fau.de