ICANN has a document at: https://www.icann.org/en/system/files/files/sac-105-en.pdf about IoT and DNS, opportunities and risks. (I liked that it had both). One point is:
5.1 Developing a DNS security and transparency library for IoT devices
The first challenge is developing and maintaining an open source DNS security library that makes functions like DNSSEC validation, DANE, and DoH/DoT available on IoT devices. The library would need to include transparent support for routine root KSK rollovers, such as automatically changing keys and notifying the DNS of which KSK an IoT device is currently using [45]. This will likely be more challenging than with traditional resolvers, partly because it may not be possible to remotely update IoT devices, and many IoT devices lack the non-volatile storage necessary to store keying material.
While the points in the last sentence are certainly true, they aren't particularly relevant. Keys are not that big compared to the code to use them. More and more often, IoT devices are updateable, the issue is that they can't really be updated if they are turned off, in a warehouse. Despite what other parts of the document suggest, I don't think that DoH is a useful thing for IoT. I think actually the opposite, but this section seems to suggest that someone, ICANN?, will be considering funding or doing some software development to make a useful validating stub resolver work in an constrained device. (OpenWRT is not really that code constrained, RIOT-OS is). I am bringing this up here, because I think that there is an opportunity here to *define* (to lead) on how to do IoT with DNSSEC and tolerating long-term offline storage. That is, if I understood this SSAC ICANN document's point. There are a multitude of ways to do this, and we have discussed this, but let me repeat the two major paths: 1) a way to upgrade from the KSK known at the time of manufacturer to today's key. -or- 2) a way to reliably (without being easily spoofed), turning off DNSSEC validation long enough to search out, and get a firmware update that has the today's keys. ---- The document goes on to talk about training, and while this part is not particularly KSK relevant, I wrote another email about this document about IoT and DNS and MUD, I think that it's worth repeating here.
* Training IoT and DNS professionals (Section 5.2) to help DNS players such as registrars and registrants understand the implications of providing services for domain names that act as a backend for IoT devices rather than as a means for making content available to humans (Section 3.3), and to help IoT device manufacturers understand how to use the DNS and how to configure resolvers (Sections 4.1 and 4.3).
I think that there is a missing element here, which is talking about DNS at IoT conferences, about the libraries one can use, but most importantly, about how to do DNS in a way that makes MUD easier to do. There is also a need to reach out to the CDN community, and deal with the question of names to IP mapping, and how we make sure that the name provides the service requested, and only that service. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-