[ksk-rollover] IoT devices and KSK rollover

[Michael Casadevall]

Very belated reply here, but we need to remember that DNSSEC information
is not sent to the end-client nodes (stub resolvers); the recursive
resolver is supposed to check DNSSEC information and then confirm
authentication via a bit in the DNS options flag. This also means that
recursive resolvers can lie about DNSSEC or simply choose not to
validate (or the client can request no DNSSEC with the CD bit)

As such, a KSK rollover should not directly affect stub resolvers as
long as their resolver resolver setup has up to date root KSK
information. If we're dealing with a device acting as a router running a
recursive resolver, obviously the above goes out the window.

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; private enterprise CAs could, but
then you need a mechanism to upload the root certificate to the IoT
device. Device manufactors also need to update their devices to update
their root store from time to time.

It should also be noted that the current Mozilla NSS root store is
approximately 250 KiB in size uncompressed. For some extremely
constrained IoT devices, that can be far too large. An ATmega328 (the
same chip in the Andrio Uno) only has a total of 32 kilobytes of space
storage space. In contact, the WolfSSL library can squeeze into ~20 kib
of flash space (https://www.wolfssl.com/products/wolfssl/)

Embedded TLS is common enough in practice (since services like Amazon
IoT require it), but often implement the bare minimium required with a
few root stores, and likely don't implement revocation checking (CRL or
OCSP) correctly or at all (speaking from experience from working on
these devices).

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.
Michael

On 6/13/19 12:14 PM, Paul Wouters wrote:
> 
>> On Jun 13, 2019, at 11:54, Fred Baker <fredbaker.ietf at gmail.com> wrote:
>>
>>> On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>>> But, if you already have TLS code in the device, then maybe it's cheaper
>>> to do this instead of DNSSEC.
>>
>> That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data).
> 
> I keep saying this too and correct people every time DoH or DoT is suggested as replacement for DNSSEC.
> 
> Browser vendors and DNS firewall vendors aren’t helping by building infrastructure that breaks DNSSEC by design. It’s an attack in the network.
> 
> Paul
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2469 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190701/84647468/pEpkey.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2468 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190701/84647468/pEpkey-0001.asc>