Re: [Iotops] comments on draft-sweet-iot-acme-00.txt

Michael Sweet <msweet@msweet.org> Fri, 29 April 2022 17:17 UTC

Return-Path: <msweet@msweet.org>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857BC15EB24 for <iotops@ietfa.amsl.com>; Fri, 29 Apr 2022 10:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msweet.org
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 elZCRSfC9qpO for <iotops@ietfa.amsl.com>; Fri, 29 Apr 2022 10:17:30 -0700 (PDT)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6C2C157B39 for <iotops@ietf.org>; Fri, 29 Apr 2022 10:17:22 -0700 (PDT)
Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id EEC0D81BF2; Fri, 29 Apr 2022 17:17:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org EEC0D81BF2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1651252640; bh=XUIeRkNDNUgLXBruMyrw8CWXXDijN7o31rBL36IvXLw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HPEpeWzLY2eQseJ9qRgwVez7ldUdv/leNOrMC1Vz13vjpWvVY13d6P96tuZk+aJkr CxbkI1YvP2cdKxQi3LRjDw63d7S9hXhKvEql3SJdv6h2QLtPyaai3EMQnjw9ywL17Q 6MksIFcKIcCyj4oZQxHzONZH769ivqi993x2sUeE=
Content-Type: multipart/signed; boundary="Apple-Mail=_D9B0EF79-2C65-4A33-8441-A240DF9F0B3F"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Michael Sweet <msweet@msweet.org>
In-Reply-To: <c36eb82a-f7f3-cf1b-f83c-90f086cf2ca2@gmail.com>
Date: Fri, 29 Apr 2022 13:17:18 -0400
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, iotops@ietf.org
Message-Id: <5E5811C3-5E9C-4F85-ADBA-CFF81EB4D097@msweet.org>
References: <164926156380.8707.8732915494613186098@ietfa.amsl.com> <B83EA69B-24B5-4FD4-BAED-6C5B34EC75B2@msweet.org> <387994.1649869389@dooku> <B665331A-A8D4-4ACC-B886-E8413F22BEA7@msweet.org> <c36eb82a-f7f3-cf1b-f83c-90f086cf2ca2@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/F-0fcYJZcFFBK-7V6ygsKH_9zl0>
Subject: Re: [Iotops] comments on draft-sweet-iot-acme-00.txt
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2022 17:17:35 -0000

Brian,

I fear we are rapidly veering away from the scope of my I-D, but I'm hoping this discussion will help to further refine the proposal...

> On Apr 27, 2022, at 11:06 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> ...
>> One problem with RFC8995 is the notion that a manufacturer should have any control over provisioning/transfer of ownership. Too many manufacturers have either gone out of business, stopped supporting "legacy" products, and/or added lock-in restrictions to their products (ink/toner cartridges with chips, etc.), leaving the customer with a paperweight in the end.
> 
> Of course this issue was debated at some length in the WG, along with the converse issue (when the original customer sells the device on to a third party). See section 10.7. "Death of a Manufacturer" in RFC8995 (and the earlier sections on used, stolen and grey market equipment).

Yeah, well that assumes that the manufacturer either starts out with a third-party solution or updates to one before they stop supporting a product or go out of business.  I'm not aware of any vendors that have done this in the history of computing, but I'm more than happy to be proven wrong... :)

In the IoT space, the most recent implosion of Insteon is an example of things going wrong, and the only saving grace for owners of their hardware is that they *can* be configured/used locally without "talking to the mothership".  They may no longer get software updates or support, but at least they can use their gear as-is.

So I want IoT gadgets that can benefit from Internet access but that don't depend on it because most IoT gear  (printers, cameras, switches, lights, thermostats, etc.) is stuff we depend on in our daily lives and is often not easy or cheap to replace, not to mention isn't easily recycled...

....

WRT RFC 8995, AFAICT it handles initial bootstrapping but not network onboarding, X.509 certificate generation for the purposes of embedded web interfaces, or adaptation to changes in host or domain names.  At the point IoT-ACME kicks in, you have already done any bootstrapping, have gotten on the network, and need to know who to trust.

For my draft I am assuming that the network client can trust the DHCP server that is giving them an address, default router, DNS server, etc. on the local network.  That trust can be extended to include an X.509 trust anchor for the network.  A local ACME server can use that trust anchor to generate X.509 certificates for IoT devices so that their embedded web interfaces can be accessed securely without throwing scary error messages in the web browser that only train users to blindly click "allow"... Another aspect of this trust is that it only applies to that network - connect to another network and the trust anchor probably will be different...

I'm currently assuming a single active local trust anchor and am not addressing certain mixed-network scenarios such as:

1. Phones connected to cellular and Wi-Fi networks
2. Computers connected to a corporate (wired) network and some other nearby public Wi-Fi network
3. Computers connected to both the local wired and wireless networks

In the first scenario, only the Wi-Fi network should use IoT-ACME since the cellular network is not locally managed and (from the OS at least) is typically seen as a point-to-point/peer-to-peer connection.

In the second case, I'd argue that the wired network should take precedence, and (at least on Windows) you can flag the public Wi-Fi network as a public network to make this explicit.

In the third case, I would expect the same trust anchor and ACME server will be used for the wired and wireless networks in homes while corporate networks often isolate the two and might only provide a trust anchor for the wired network. But like the second case I'd argue for wired over wireless if it isn't feasible to target X.509 validation based on a socket's network interface.

________________________
Michael Sweet