[ksk-rollover] IoT devices and KSK rollover

[Michael Richardson]

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 at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190612/b4ff4ba8/signature.asc>