On Thursday, 3 July 2025 23:12:36 CEST Phillip Hallam-Baker wrote: > I am very much aware that my work risks waking sleeping dragons. But those > dragons wake regularly anyway. Inflicting a miserable user experience on > our users is not an acceptable approach to mitigating our security problems. > > People have always been telling me my proposals risk causing unspecified > harms in poorly understood infrastructures. To which my response has always > been to say I will be very willing to help understand and fix those > infrastructures but if your Plan A is asking PHB to not risk breaking > something, you had better start thinking of your Plan B. Hahaha, it would not be IETF without the sleeping dragons! For better or worse, at least they keep us in check. Um.. they.. we? Have I turned into what I sought to defy? :) Honestly, no hard feelings here. Shared goal is to make the Internet as good as it can be, and I'm all for that, and doing it together. > In the short term, this is going to be a toolbox for people to use to build > their own IoT devices while also serving as their own HSP. I fully agree > that most IoT devices are terrible. But they don't need to stay terrible. Hear hear! The idea of providing guidance and infrastructure for making devices that are secure, whichever they may be, I like that. That's one of the things I really missed when doing my smartwatch project, how do I even get started with this? Not just outsource it to microPython or whatever, I wanted to learn C and that was a great springboard. No heap and such, and pointers are used but not by much. I liked that, and kinda wish I'd known in advance. Good documentation, an actual platform that's actually used and cross- compatible, like HomeAssistant aims to be, would go a really long way. And that way you don't really need a remote server to have devices phone home to either. For those who don't have HomeAssistant or such I guess yes, but then a given developer could branch into conditional logic as to whether a local server is present or not. And then that local server could WireGuard into a server on the Internet, and/or have a port-forwarded administration interface, etc. > The Microsoft .NET infrastructure provides one very comprehensive platform > for building memory-safe IoT devices. I am not fully up to speed on the > current state of Rust in the IoT space but I understand it was close a year > or so ago. And it is not like IoT devices need a lot of complexity. > > A smart doorbell needs one button, some cameras, a microphone, a > loudspeaker and some networking. Building on top of dotNet Core and running > that on Raspian allows us to present a much smaller attack surface than > typical IoT devices. But yes, running the dotNet Core runtime direct on the > RaPi metal without having all of Linux along for the ride would be even > better. This is one of the things I like about Arduino. Raspberry Pi's are boards I use extensively for applications that use Linux, e.g. my network gateways are powered by two of them on a UPS module. GPIO is something I don't use too much on them though, both due to being 3.3V logic (as limited by their Broadcom CPU), and due to not really understanding how to interface with it too well. I dunno, a Python script with a systemd service or such, that at least gives it a button to shut down the system.. maybe. And for stuff that needs onboard networking as well as Linux, sure why not? But for power consumption, UPS vs. straight to battery, the sensitivity of those particular boards to undervoltage, ... And then of course the whole OS stack on top of it too, with its slew of vulnerabilities! I don't think one is better than the other, rather that they are different. But having a platform like that, it's absolutely crucial. It's only once you have the prototype figured out, that you can start thinking about moving into an ATtiny85, a Padauk, or PIC microcontroller or such. > I didn't address the issue of segregating the home network in the original > post because it is orthogonal to the HSP proposal. But it is an approach I > very much want to follow in my own home setup. The connection experience > has to be seamless for the user regardless of what type of local network > management he has deployed. If they have a 2025 standard Internet router, > their device is going to be onboarded and provisioned direct into their > local network. But if they have something like an appropriately configured > Ubiquiti router, when the device first connects, it will only get access to > the quarantine network. And the production network will be segregated. I actually like the idea of such HSP in the long run, especially if it runs on a vendor-agnostic DNS infrastructure. Maybe we could argue the position of ICANN there, but for all intents and purposes, even local zone files are possible, and so I would consider it sufficiently vendor-neutral and rooted into an actual established protocol. To have writing as to how this would tie into the DNS, would be very useful. Once that's done, we could then bring that into DNSOP as well. More than willing to do that together, I'm an existing member there. > And I am pretty sure that if we can put together a crisp specification for > what a secure home network looks like, there will be broadband providers > more than willing to push out updates. Security breaches end up as customer > service costs for them. I love the way you think here! Cost-benefit, yeah, customer service departments are the ones to face the angry customers whose data and/or networks have been breached. If we can offer guidance on how to prevent that outcome, why wouldn't they consider it? I think this is something worth doing. -- Met vriendelijke groet, Michael De Roover Mail: ietf@xxxxxxxxxxxx Web: michael.de.roover.eu.org
