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@gmail.com> wrote:
On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr@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@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.