July 2019 - ksk-rollover - lists.icann.org

Retention of the 2010 KSK
by Kim Davies Sept. 25, 2019

Sept. 25, 2019

Just confirming my mic comments: Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK). kim

13 24

IoT devices and KSK rollover
by Michael Richardson July 2, 2019

July 2, 2019

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(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

7 11

Re: [ksk-rollover] IoT devices and KSK rollover
by Paul Wouters July 2, 2019

July 2, 2019

On Mon, 1 Jul 2019, Michael Casadevall wrote: > As for DoT/DoH, none of the above changes as there are no wire protocol > changes to DNS in either of these use cases, and the cost of > implementation is stupidly high. First off, it's impossible to deploy > DoT/DoH in an internal network that uses RFC1918 address space (aka > 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue > certificates for this address space; what prevents you from requesting a certificate on an internet connect IP using ACME, and then moving or also using it on the internal IP pointed to by internal only split DNS ? > Device manufactors also need to update their devices to update > their root store from time to time. I guess it really depends on your definition of IoT. > It should also be noted that the current Mozilla NSS root store is > approximately 250 KiB in size uncompressed. Why would an IoT device need the whole firefox or other vendor root CA store? Again, it really depends on what you call an IoT device. > There are major issues with DoH/DoT in general, but a lot of devices in > general are going to simply incapable of supporting it because the cost > of full TLS support + full set of CA root certificates is simply too > high in terms of flash storage. Maybe IoT devices shouldn't need to talk to the internet at large? And their trust model can be minimzed to the little things it needs? Paul

4 3