[ksk-rollover] IoT devices and KSK rollover

[Mark Andrews]

> On 2 Jul 2019, at 12:50 pm, Michael Casadevall <michael at casadevall.pro> wrote:
> 
> Replies inline. Apologies but this is wordy, but from where I'm sitting,
> userland applications can't do anything to prove DNSSEC is both correct,
> secure and available. If I can be proven wrong, I'll gladly admit so.
> 
> On 7/1/19 7:10 PM, Mark Andrews wrote:
>> 
>>> On 2 Jul 2019, at 12:57 am, Michael Casadevall <michael at casadevall.pro> wrote:
>>> 
>> 
>> 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.
>> 
> 
> The world you described is the world I'd like to live in (DNSSEC
> validated through the stub), but not the world we live in. I'd be happy
> to be proven wrong but here's how I see the world. Two examples, the
> Windows operating system's stub resolver, and Postfix's DANE support to
> show how bad of a world this really is. Let's look at Postfix first:
> 
> Postfix support DANE validation for STARTTLS records. DANE requires a
> zone be signed via DNSSEC. The code responsible for that is here:
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dane.c#L965
> 
> or more importantly, this line:
> 
>    ret = dns_lookup(tlsa_fqdn, T_TLSA, RES_USE_DNSSEC, &rrs, 0, why);
> 
> dns_lookup is a macro defined to dns_lookup_x
> (https://github.com/vdukhovni/postfix/blob/master/postfix/src/dns/dns.h#L229).
> This leads to dns_res_query(), and then finally to the glibc.
> 
> res_query's manpage
> (http://manpages.ubuntu.com/manpages/bionic/man3/res_query.3.html) has
> the following to say on the subject:
> 
>       int res_query(const char *dname, int class, int type,
>              unsigned char *answer, int anslen);
> 
> On DNSSEC, it says the following:
> 
>       RES_USE_DNSSEC
>              Use DNSSEC with OK bit in OPT record.  This option implies
> RES_USE_EDNS0.
> 
> The long and short version is that Postfix's DANE support requires the
> DNS resolver pointed to in /etc/resolv.conf
> 
> 1. support DNSSEC
> 2. Properly implement KSK-2017
> 3. Not lie about the status of the AD bit.
> 
> As of writing, here's what my /etc/resolv.conf says while connected over
> Wifi at my mom's apartment:
> 
> mcasadevall at dawntreader:~/src/postfix-3.3.0$ cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 10.0.0.1
> 
> 10.0.0.1 is a *very* cheap NetGear router. A look at the router's
> settings page suggests it's just a forwarding resolver pointed at
> Verzion FIOS's DNS servers which it got from upstream DHCP.
> 
> ---
> 
> The situation on Windows is even worse. Right off the bat, It does not
> ship with a DNS server out of the box listening on ::1 so any and all
> behavior exists solely in the stub resolver (which is part of Winsock),
> and Microsoft only provides a DNS server on Server editions of Windows
> (which is not installed by default).
> 
> In almost all application code, a call for a domain name (to get an
> A/AAAA) record is either going to be done by getnameinfo() or
> DnsQuery[Ex](). Both of these functions are essentially standard for
> tutorials for doing socket programming with Winsock (esp.
> getnameinfo()). That DNS query is going to go to the network adapter's
> default DNS resolver which is usually going to be set by DHCP by the
> router. The router may set itself as the server (where it may just be a
> forwarder or a recursive resolver), point at the ISP, or possibly point
> at a public DNS server such as 8.8.8.8.
> 
> The stub resolver will not check DNSSEC information, leaving it to the
> upstream server to do it's job for it (and should return BADSIG, etc. if
> DNSSEC is broken). I've spent the last hour looking through MSDN, and I
> can't find a single API that validate DNS traffic against DNSSEC
> directly or check DNSSEC record validity. It doesn't even appear I can
> reuqest DO=1 via the DnsQuery API
> (https://docs.microsoft.com/en-us/windows/desktop/DNS/dns-constants; see
> DNS Query Options). I spent the better part of an hour searching MSDN
> for this.
> 
> The only functionality that directs the behavior of the stub I can find
> is the Name Resolution Policy Table  (NRPT). NRPT is controlled by group
> policy (usually through Active Directory) and can change the behavior of
> the DNS stub resolver to require validation. The mechanism for changing
> and updating trust anchors for the stub resolver appears directly tied
> to Active Directory and it's DNS server; I don't have a local AD tree to
> test at the moment.
> 
> There's no way as far as I can see to directly get the status of the AD
> bit on Windows (I'll be happy to be proven wrong) or load and change KSK
> trust anchors unless a machine is part of a domain and said trust
> anchors are distributed through active directory. The Windows Server
> documentation details how to do this.
> 
> 
>>> 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.
>> 
> 
> How?
> 
> Applications can't even trust DNSSEC information (if available) with
> current APIs and libraries and the tech has been around for two decades.
> 
> KSK-2017 was deployed in Ubuntu and Debian by doing SRUs for all the DNS
> servers to add it to bind.keys or it's equivalent. RFC 5011 only worked
> while KSK-2010 and KSK-2017 were both in the root; KSK-2017 was manually
> added to bind.keys so that BIND could work and bootstrap itself on new
> installs on older distros (i.e 16.04) that predate KSK-2017 or on
> systems enabling dnssec-validation now post-KSK2010's removal.

bind.keys was made a seperate file so that it was easy to update.  Yes, we 
expected distributions to update it the same way as they update the CA bundle
from time to time.  Named has a copy of bind.keys compiled into it to use if
bind.keys is not available.

> We don't have a mechanism that allows for bootstrapping a new KSK unless
> the old one is still in the root. For software that gets clean installed
> when a new KSK is installed, they won't be able to bootstrap to the
> latest KSK.

Nothing crypto can bootstrap itself and be 100% secure.  It is mathematically
impossible. Complaining about that is like asking for a unicorn.  You can ask as
much as you want but it will not happen.

Hardware reset + trust on first use works reasonably well.  That is essentially
what lots of us do for WiFi.

The equivalent of

“dig +short dnskey . | awk ‘$1 == 257 { … }’ > tmp”

with sanity checking before moving into place.  

> Furthermore, there is no standardized API for validating DNSSEC
> information outside of a DNS recursive resolver implementation (AD=1).

There is no standard resolver API.  Posix doesn’t have one.  getaddrinfo()
sits above the resolver.  That said there are a number of resolver
implementations that are available and are compliant with STD13.

res_send(), res_search(), and anything else that returns the full answer.

	bool ad = buf[3] & 0x20;

Yes, this is working at the level of the resolver.

> I'm unaware of a library that I can drop into my code, does DNS for me
> on my behalf (with or without the system stub resolver), and compares it
> to a list of KSKs I know is valid. Even if said library *existed*, we'd
> just extend the number of places that breaks on a KSK rollover, and due
> to the previous paragraph, that's a *bad* thing.
> 
> If you want that, you can install dnssec-trigger. dnssec-trigger however
> causes additional load on both the root and intermediary servers by
> causing additional lookups to do DNSSEC validation.
> 
> Userland applications have no way of knowing if their DNS responses are
> going to a trusted source, most end users are just going to accept
> whatever their DHCP server tells them, and most recursive resolvers
> can't be trusted.

The point of doing DNSSEC in the app is that you do not have to trust
the resolver.  You can verify the answer yourself.

There are a number of DNSSEC capable libraries that can validate answers
you get back from upstream.

This isn’t a matter of the technology not being available.  It’s a matter
of people not using it.

Mark

> Michael
> 
> <pEpkey.asc>

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