Phillip,
> On Dec 18, 2024, at 1:39 PM, Phillip Hallam-Baker <ph...@hallambaker.com>
> wrote:
>
> I have been thinking about this problem for a very, very long time. I don't
> see ACME as the solution to the IoT certificate problem because it is
> designed to support the WebPKI which is predicated on DNS names.
Um, that's exactly what web browsers and TLS-using protocols depend on. I
don't want an out-of-band solution that doesn't work with a web browser or
existing protocols...
> Let's forget about mDNS for a while. mDNS was a hack designed to allow people
> to set up printers in small networks where splattering multicast messages
> made sense and telling people to deploy some sort of hub service did not.
It has always been about more than printers, but I'll grant you it doesn't
scale well to enterprise networks. But then the focus of the SETTLE mailing
list is *residential* networks...
> My FiOS home router has a full DNS server on it and I am pretty certain every
> other home router does as well.
Um, no. Even my Ubiquity ("enterprise") routers don't have a DNS server
running by default (although it *is* an option). OpenWRT provides dnsmasq
which only provides the most primitive of DNS services from the /etc/hosts file
on the router.
> So the problem here is how to push the data we need for resolution into the
> DNS tables on that device or to move DNS resolution to a different device.
> Does multicast make sense in a home network with 100 IoT devices? I don't
> think so. Lets not start off with a commitment to some 20 year tech because
> it is there.
FWIW, my current IoT ACME draft does talk about the limitations of mDNS and the
preference for regular DNS.
That said, 100 devices on a home network is not unusual and is easily
handled/managed via mDNS. Where mDNS falls apart is when you have more devices
than can fit on the local network segment/subnet. But *that* isn't common for
residential networks.
> What I propose is a two phase process:
>
> Phase One: To provision 'PHB-connect' devices, first deploy an 'always on'
> PHB-connect hub, which is merely an RaPi ZeroW class device.
This is called "prototyping"...
> Phase Two: All the functions of the hub are absorbed into the home network
> router interface or some other device in the network that has the 'always on'
> property.
and this is deployment...
> Let's start from the beginning as the user sees it. A box arrives on their
> port. They want to unbox the gadget, power it up and use it with the absolute
> least fuss possible:
>
> * Scan a QR code on the box or the device
> * Use the camera on the device to scan a QR code presented by some existing
> device
> * During the online purchase, click a box to pre-connect it to my network, on
> delivery, confirm the join request on existing trusted device.
There are things like Matter that support this sort of onboarding experience,
and I don't have a problem with using this if it means we can validate a
device's identity and ultimately use that to generate trustable X.509
certificates.
> This is one of those problems where it is MUCH EASIER to solve the whole of
> the user's problem than just one little bit. If I am doing the whole
> onboarding process, I am already talking to the DHCP service, the DNS service
> and the 802.11x/RADIUS service.
>
> If we are going to provision a TLS cert to the device, we can step up and
> provision a better way to connect to the WiFi networks (ALL OF THEM), than a
> global password. Home users need enterprise grade security MORE than
> enterprises do.
First, we can't focus exclusively on Wi-Fi. Second, Wi-Fi security is
basically controlled by the Wi-Fi Alliance and not the IETF. So personally
while I agree that better security is needed for Wi-Fi, this isn't the place
for that discussion.
> There is also the question of naming, there are many variations, but the ones
> I have seen all boil down to three underlying approaches:
>
> A) Use a DNS name, costs the user $10/yr for all their devices
Um, *what* root domain costs only $10/yr? And why do you think that every
network will have Internet connectivity? And who are we to sign the whole
world up to require paying to have local trust?
> B) Use a fingerprint of a public signature key as a personal root of trust,
> cost $0 but horrible usability
>
> C) Introduce a new universally unique identifier as a friendly name for B.
>
> Case A is pretty much solved already. Just a case of joining up the dots and
> letting a device inside a private NATed network get an ACME accredited cert.
> Result works with an unmodified standard browser.
Case A doesn't work for local IoT devices since there is no way for global ACME
to validate a local (inaccessible to the world) device, short of some sort of
dynamic DNS solution which has its own issues (configuration and internet
connectivity are two big ones).
> Case B is flexible but ugly. We have no problem with .onion addresses or PGP
> fingerprints but almost everyone else does.
Given that one of the goals of the SETTLE list is to "discuss securing access
to TLS local resources", I don't think that ".onion" addresses or PGP
fingerprints address a problem we are trying to solve.
> Case C does have a cost but it can be very, very low. I believe a wafer-thin
> registry can be run for a $0.10 one time fee. And the main reason to charge
> is that domainers would slam the service otherwise. That is low enough that
> an IoT vendor can provide a coupon redeemable for a name registration if the
> user needs it in every box. Or we can get clever and elide the need for a
> paper coupon.
First, I don't see how we can declare a cost/price for such a service, nor can
we expect the world to pay for it or that networks have always-on Internet
connectivity (or any connectivity at all).
Second, there is a long history of issues associated with single vendor
solutions.
> ...
> Device is registered using the existing Mesh device connection protocol which
> causes it to be provisioned with a set of public/private keypairs for
> authentication, signature and encryption. It is also assigned a unique IPv4
> address in the space 10.x.x.x and a globally unique IPv6 address in the ULA
> that won't change even if Alice takes the device to one of her other homes.
And what happens when Alice sells the device or needs to do a "factory reset"?
Also, current residential routers almost all limit IPv4 addresses to /24's in
the 10.* and 192.168.* ranges, which limits the number of "unique" IPv4
addresses a router can hand out...
> [While DHCP means that devices can in theory change their IP address if they
> are offline and come back, this only makes network management harder and more
> confused. Giving the device a unique address that will never change for as
> long as Alice owns it allows us to automate VPN management later on.]
VPN implies some sort of remote access/routing to/from another (private)
network.
And reiterating my previous comment, IPv4 addresses are scarce which is why
DHCP dynamically assigns them. It's in the name...
> If the device has a CPU that is designed to support it, we can bind the Ed448
> and X448 private keys the device is going to use to the device itself using
> threshold cryptography. This makes leak of the private key very, very
> unlikely unless the device itself is physically compromised. This in turn
> means we can worry a lot less about key compromise and certificate expiry.
>
> So when the device connects, if it has secure storage, can just issue it a 10
> year cert under Alice's personal root.
First, IoT devices have a lot longer life than 10 years. Second, browsers only
accept certs with much shorter lifespans. This is one of the reasons why I
keep coming back to ACME - we need certs that are automatically (re)issued...
________________________
Michael Sweet
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
