Date: 27 October 2022, 11:00 – 12:00 (UTC+2)
WG Chairs: Peter Steinhaeuser, Sandoche Balkrichenan
Scribe: Alun Davies
Status: Final
Peter and Sandoche welcomed attendees and opened the session.
Michael Richardson, Sandelman Software Works
Michael Richardson opened the session with a talk on measuring the trust in trust anchors. Michael shared an IETF document he has been working on, entitled 'The taxonomy of operational security considerations for manufacturer installed keys and trust anchors'. The presentation was focused on sharing what the document is all about and why he came to write it in the first place.
You can find the presentation at:
https://ripe85.ripe.net/archives/video/950
Benedikt Stockerband (Stepladder IT Training+Consulting GmbH) suggested that the talk didn't account for the number of auditors, suggesting that if someone wants to compromise a system, they'd go for the auditor if there's only one of them. He added, we have certificates and we have certificate authorities, and these don't always do their job. This can be a real problem, potentially breaking the entire system. So another option would be to have one CA that people really take care of (perhaps with government pressure). Benedict asked if there's a 'sweet spot' where the numbers really make sense and beyond which they start to get counterproductive.
On the second point, Michael replied that there are web PKI CAs involved in the CAB forum that the web browsers trust. But in the IoT space, these can't be used. The lifetimes that are enforced are too short, the policies are wrong -- so in most cases manufacturers for the purposes of producing a birth certificate (for example) end up talking about spinning up their own private PKI. And they also talk about the the opposite, which is the trust relationship where the software updates happen, which doesn't require public CA. So the number of CAs that we are going to have in the future will run to thousands and thousands of private ones. That's the concern here.
Going back to Benedikt's first point, Michael replied that we know about the certificate transparency problem, and while it's an interesting problem, it only applies IoT devices that exclusively call the Cloud using a public anchor. And that's not always the case - you don't have to use a public anchor.
Michael used a pause in questions to emphasise that he would really appreciate comments.
Sandoche (WG chair) asked about private PKI and certificate authorities. He pointed out that there is work going on in the Working Group at the IETF where they are looking at how DNS could be used as a public key infrastructure for IoT. His question was whether it is possible to reinforce the auditing for IoT?
Michael answered that he doesn't think so. The question is not about how the public key gets to the relying party, but what care did the owner of the private key take to make sure the private key stayed private. If we are talking about client side TLS authentication, then the private key is going to be in the IoT device. The 'stupidest' way is to have the private key sitting there in flash and you can just pull the flash out and read it. The more complicated way is to have an FTPN inside the CPU that has the key, and only the maker of the CPU could ever break it. That's two completely opposite levels of security. So for Michael the real thing to ask is, where are you on the spectrum. While he doesn't want his medical keys sitting in flash, he also doesn't want to pay top buck for a talking Barbie that doesn't really need that much security.
There were no further questions.
Peter Steinhaeuser, embeDD
Peter Steinhauser presentation also looked at trust and onboarding IoT devices, but from the management level. He looked at another approach to solving security issues for IoT based on MUD.
You can find the presentation at:
https://ripe85.ripe.net/archives/video/954
Michael Richardson asked how long Peter and his colleagues had been watching the traffic and how they become confident that they've observed all relevant behaviours.
Peter acknowledged that this is one of the really tricky questions in this area, adding that at the moment the approach is to monitor devices for a day and take what happens during this day as an initial collection of information. He added that the main idea is to have something to start from. But in case the behaviour changes, for MUD files and for this device description, then we have the interesting questions of how we can maintain them. It's not only about creating the files, but maintaining them. There have to be iterations: parts can change, addresses can change, etc.
Michael followed up that while that is very much focused on the user side, it seemed that Peter and colleagues are also doing work on the ISP side of things. He added that there was a scary comment about ISPs getting alerts. He suspected it would scare ISPs because false alarms are so expensive. So he asked if Peter had any ideas about how that's going to evolve.
Peter responded that ISPs are a very interesting field here. He had had several talks in the recent weeks and the bad news was that most of the ISPs still have no clue how to approach IoT devices. They have no clue of what they want to achieve on the technical side of things. On the marketing side they don't know how to monetise it. But, he added, it is not our job to tell them what to do here.
Michael responded that we might as well form an opinion and they can disagree as at least a conversation would take place that way.
Peter agreed and suggested that - just as the first BCOP document of the RIPE IoT Working Group was a good starting point as a collection of ideas - maybe another document would be useful focusing on ISP use cases to give them an idea.
Michael agreed that a new document would be a wonderful idea.
Martin Winter (NetDEF/OpenSourceRouting) asked if how it was currently possible to experiment with this. Peter responded that the Unet‑acl itself is already there and the IoT part is currently in implementation. He added that a first running version should be available at the end of the year. Martin also asked whether there's experimental code available, to which Peter replied that this is still under implementation, but he could connect Martin with the relevant department.
Sandoche asked if Peter had any idea as to the percentage of IoT devices being implemented using OpenWrt. Peter replied he hadn't heard of IoT devices using OpenWrt, probably because the resource requirements are way too high for a common IoT device. While it would be possible to run a surveillance camera, for instance, for typical devices OpenWrt is not the right software platform.
Edwin Verheul (SURF) asked about DNS resolvers. Since Unet‑acl also covers DNS‑based requests, one question to ask might be which DNS address is the device contacting to create the profile and to enforce rules.
Michael Richardson asked if he could respond. He said that this is a complicated question and there's an IETF draft for that that he would love comments on. He added that, you'd better make sure your IoT devices do not do DoH to Google or Cloudflare because then you can't learn what names they looked up and, more importantly, when you look up the names in the ACL, you might get a different answer than they did, and then your ACLs don't work. This means you get false positives, the ISP complains, and MUD gets turned off. He added that, while that's the negative side, there's a bigger discussion there that probably doesn't impact us.
There were no further questions.
Nick Allott, Nquiringminds
Nicholas presented on the collective work of around twenty organisations who have come together under the IoT security foundation. Looking at security IoT gateways, Nicholas aimed to highlight industry challenges and the approaches these organisations are are taking together to try and solve them.
You can find the presentation at:
https://ripe85.ripe.net/archives/video/956
Peter Steinhauser asked about D3 aggregators. He asked whether there were already aggregators available that you could work with for research reasons. And asking how aggregators actually worked, he asked whether these are community‑funded or have a more commercial background, or some mix of both.
Nicholas responded that the commercial approach is complicated. Going into detail on some of the issues, he added that as things evolve the manufacturer would ideally be the trusted source of that information. There would probably then be a need for more commercial aggregators to aggregate that. The ideal solution would allow that transition between crowdsourced to industry moderated manufacture sourced information in a fluid way rather than it being a big bang because that's the classic network problem. He finished by noting that we need to be creative about these complications.
There were no further questions.
End of session