On Thu, Jul 3, 2025 at 4:15 PM Michael De Roover <ietf@xxxxxxxxxxxx> wrote:
On Thursday, 3 July 2025 03:50:15 CEST Michael De Roover wrote:
> For the time being, it's quite late at night and my brain is admittedly
> starting to shut down. I have so far read until here, will try to do my best
> to read more into it tomorrow. I have a bad habit of taking on more
> projects than time allows though.. so no promises.
Well, that should've been a red herring... Now with a clearer mind, it seems
that I completely missed the mark on the IoT-centric subject matter. Sorry
about that.
The concept of a Handle Service Provider is not limited to IoT and that is not where I see the initial wins coming from. I see the initial benefits being support for an OAUTH Id that is actually open (because it is a DNS name not an account with one of five members of a cartel) and the presence service enabling end to end communication in an open service model. So Alice can place a phone or video call with Bob even if they use different HSPs.
I don't see the IoT part as being feasible for deployment for several years. First because it needs the Identity and Communications service areas to build the necessary critical mass. But also because we are several years off being able to do it right.
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.
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.
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.
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.
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.
