[ksk-rollover] IoT devices and KSK rollover

[Paul Wouters]

On Tue, 2 Jul 2019, Michael Casadevall wrote:

> We can do better than RFC 5011. In the TLS world, operating systems
> maintain stores with valid root certificates. As CAs rise and fall, the
> root stores get updated, old software can connect to new CAs and things
> just keep working.

operating systems maintain DNSSEC root keys outside of 5011 as well, as
part of their OS update mechanism. Whatever works for updating root CA's
works for updating DNSSEC root keys.

> Right now, for the KSK, the only mechanism for distributing root keys is
> downloading them from IANA or RFC 5011 if you're a DNS server of some type.

It's not. Debian/Ubuntu have a specific package that distributes the
root keys. RHEL/CentOS/Fedora ship DNSSEC keys with the various DNS
packages.

>> “dig +short dnskey . | awk ‘$1 == 257 { … }’ > tmp”
>>
>> with sanity checking before moving into place.

> I'll agree that this is likely better than the current situation with
> RFC 5011.

It's not better. It depends on your "sanity checking" of course, but
this solution sounds more like a "better than nothing" solution. And
I can see malware abusing such a mechanism if such mechanism is widely
used. Just wait for a >5 year old IoT device to reboot, and you own it.

> However, this behavior should be standardized via RFC or at
> least a BCP.
>
> That being said, if we can do better, we should.

It would be nice to do better, but it is currently unclear how to.
Various solution suggested in the past all fail if one of the Root
keys is ever leaked/compromised.

> res_* are a de facto standard; they're originally from BSD 4.3, and
> exist in one form or another in every major UNIX and UNIX-like distros.
> Granted, not all implementations support DO=1, but the API itself is
> very wide spread. Furthermore, the DNS client library is beside the
> point beyond being able to retrieve records and checking the status of AD.

>From what I'm seeing, the use of c-ares, libunbound and bind libraries
are seeing increased use for in applications. Any libc based functions
are being used less and less. (eg get_addrinfo(), gethostbyname*()

> That being said, we're talking more about just the capabilities of the
> resolver.

A full DNS resolver has little use for POSIX. they have their own
resolving code. The interesting bits are stubs and applications. Those
are the ones that benefit the most from a good API supporting DNSSEC.

>> The point of doing DNSSEC in the app is that you do not have to trust
>> the resolver.  You can verify the answer yourself.
>
> By the standard you set, checking the AD bit by itself is insufficient.

He said "in the app", so the AD bit there just signifies the result was
secure. In libunbound terms that is ub_result->secure. It denotes all
the validation was done inside the app/library. Mark did not mean an AD
bit over the wire.

> The problem is I need a library to validate the DNSSEC answer. That's
> the wrong solution.

With dns-query-chains (and hopefully tls-dnssec-chain) you just need a
library that validates such a chain, without any dns cache or direct
querying.

> The correct solution is the operating system (or whatever you're using
> for DNS and sockets) should be doing this transparently when I tickle
> gethostbyname() and friends. Fixing an application at a time to validate
> DNSSEC is like subtracting one from infinity; we're not going to get
> anywhere like that (this is a point I've been trying to hammer in UASG
> in regards to "oh, just use this third party IDN library and fix every
> place your app uses domain names").

It really depends on the application and its trust in the OS. If you are
pulling IPSECKEY or OPENPGPKEY's from DNSSEC, I would prefer the
application does not depend on the system's resolver. Perhaps for
pulling TLSA records, it is good enough.

> Great, now that we have a BCP, we go to glibc, and write a patch that
> implements DNSSEC validation at the resolver level with a new flag to
> opt out by setting DO=0 (or CD=1 depending on your needs) and justify
> the change by pointing at that BCP. Boom, you've fixed it for all Linux
> distros.

glibc is ejecting DNS code, not taking in new code. c-ares seems to be
were this is concentrated these days (at least in my limited view)

> We go to Mozilla and add support to NSS/NSPR, boom, all Mozilla
> applications now do it correctly out of the box.

Having been on the sidelines of two attempts to get this done, I wish
you a lot of luck. I really hope you succeed, but at the moment I
wouldn't focus on Mozilla. They are not helpful at the moment.

> Add DoT/DoH on top and we have a nice shiny secure DNS ecosystem. KSK
> updates can happen as part of standard security updates and all apps get
> fixed at once. Everyone wins.

DoT/DoH seems to be more used to pretend we don't need DNSSEC :(

> It's 2019 and we've still got lots of things that go boom on pure IPv6
> networks and that's been going almost 25 years now and that has a *lot*
> more incentive for developers than checking DNSSEC status in the
> application layer, especially since most developers aren't even aware
> DNSSEC validation affects them at all.

I'd settle for the low bar of "don't work against us please".

Paul