On Wed, Dec 18, 2024 at 5:00 PM Michael Sweet <msw...@msweet.org> wrote:
> 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.. > Seems you didn't get to the line at the end of my piece... If you had read the post before starting to reply, you would see that I addressed this very issue. I do have some experience getting root keys into browsers, you know. The WebPKI was designed to address one specific set problem, to make shopping online as secure for the user as mail order. If I can get the IoT vendors to adopt this particular proposal, I am pretty sure the browser providers will be more than happy to add a root to support the approach. But even if not, the real issue is being able to connect to the devices securely. I don't see having to use a different browser to talk to my IoT as being a huge inconvenience. > 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"... > No, I think we can sell this as a go-to-market solution for the Chinese IoT vendors who only want to sell product and want as little to do with services and apps as possible. > > 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... > It is really not a priority. > > 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. > Wasn't claiming to be original. Was claiming I have a solution that works and is coherent. > > 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. > Wired is a vastly simpler problem. I don't much care about turf wars. WiFi alliance has failed to address the obvious usability failures of their system for decades. I care about the users. And so do the companies who want to sell IoT, most of whom have never been to a WiFi alliance meeting and never will. > > 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? > The PIR sells .org names for less than $10/yr. And you really should have read the post before responding and you would see that I answered your question. > > 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). > The $10/yr is a much bigger blocking issue for IoT vendors. I can solve these issues for pennies and do so in a way that doesn't tie stuff to the IoT manufacturers services so they brick when if they go out of business. > > 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. > Enumerating the solution space for completeness. > > 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). > I can because I have experience of the costs. I can do it at that price point. > Second, there is a long history of issues associated with single vendor > solutions. > Which is why it would have to be a public interest resource that is appropriately controlled and accountable. > > ... > > 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"? > I have considered offboarding. Basically, there is a single key that is overwritten and the thing is completely reset to factory. 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... > Lets say you want to partition devices by VLAN and have 256 of them. That is still 65,536 addresses. I am not seeing a good argument for randomizing address assignment. Each machine just gets the next IP address in order. Only reason to reuse an address is replacing like with like or in the unlikely event you run out and start again. And reiterating my previous comment, IPv4 addresses are scarce which is why > DHCP dynamically assigns them. It's in the name... > Scarce globally but not really at network level. Each building gets their own network. Have to be a very big building to run out of a /16, let alone a /24. And if it is that big, it should have internal partitions and firewalls anyway. > 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... > If the cert expires, renew it.
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
