[ksk-rollover] IoT devices and KSK rollover

[Mark Andrews]

> On 2 Jul 2019, at 12:57 am, Michael Casadevall <michael at casadevall.pro> wrote:
> 
> 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)

What a load of hogwash.  DNSSEC is designed and expected to be performed
by *every* entity in the resolution chain.  The AD bit is only supposed
to be accepted if there is a secure path between the recursive resolver
and the application.  99.999999999% of the time this is not the case unless
you are talking to 127.0.0.1 or ::1.

There are applications that perform DNSSEC through stub resolvers.

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

This is short sighted thinking.  One should design for ubiquitous DNSSEC
regardless of whether it is achieved or not.  This lets those that want
DNSSEC all the way to the application have it.

> 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.
>> 
> 
> <pEpkey.asc><pEpkey.asc>_______________________________________________
> 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org