[ksk-rollover] IoT devices and KSK rollover

Tue Jul 2 02:50:23 UTC 2019

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.

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.

Furthermore, there is no standardized API for validating DNSSEC
information outside of a DNS recursive resolver implementation (AD=1).
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.

Michael

-------------- 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/bf9a5c3f/pEpkey.asc>