[RSSAC Caucus] Threat Mitigation for the Root Server System

[Paul Vixie]

Michael Casadevall wrote on 2019-10-02 00:30:
> Looking at the document, one thing that jumps out of me is both data
> integrity and route hijacking. I feel like this document puts far too
> much faith in validating resolvers to catch compromised root servers and
> route hijacking.
> 
> When I did work on creating a root server emulation setup for testing
> root IDNs, generally speaking, unless I went out of my way to force
> strict compliance, non-signed/invalidly signed data would just be
> accepted if it came from the roots even before I inserted my fake KSK
> into the mix.
> 
> The short version, is if I can pop a root server and inject malicious
> traffic, I can't tamper with the root server data without causing
> signature validation failures. I *can* freely change the NS records to
> MITN any DNS lookups to a TLD especially if I'm just echoing signed
> data. That's a pretty darn effective way to essentially cast a dragnet
> on all lookups to a TLD.
> 
> Furthermore, I'm not convinced that the recursive resolver
> infrastructure as a whole will properly fail if someone injected a bad
> zone into the root. The defaults on far too many things are to soft-fail
> vs. hard-fail.

it's vital that we find out how common this behaviour is.

data exfiltration by unsigned (delegation) NS RR is not concerning, 
since the data is public, and since in the earlier part of the story a 
root name server had to be compromised -- so exfiltration is already on 
the table, be it from one vantage point or another.

however, if soft fails are sometimes ignored, we need to study it closely.

> The canonical example I can bring out is .local/.lan. These TLDs are
> common in private networks, and if my understanding is correct, the
> roots get pinged for these TLDs all the time. The root server send
> NXDOMAIN (with signed NSEC if DO=1) but these hosts still (presumably)
> work for the locations that use them. If recursive resolvers were
> hardfailing for non-existant TLDs, we'd see a lot of pain when the root
> zone was originally signed.

generally speaking, local names like .lan or .local (or .tor) are 
handled as "hosts file fallback" or as a plugin, and those namespaces 
rely on an NXD response from DNS in order to open up the next namespace 
in their local logic path.

> Taking the case that I've popped a RSO, and can control one of the root
> servers zonefile freely, I can delete all DNSSEC data and just send
> whatever records I like. How much of the validating recursive
> infrastructure is going to properly hard-fail if they receive unsigned
> data, or a mix of signed and unsigned data?

all of it. the RDNS config includes a binding from a static key to some 
subtree of the DNS -- often called a "trust anchor". in bind9 as 
observed, if it gets unsigned data for a subtree (such as ".") that has 
a trust anchor defined for it, the stub resolve will get a SERVFAIL answer.

if _any_ available validating RDNS does not behave that way, we need to 
set our hair on fire until we get it either fixed or shamed/decertified.

> Speaking from my position on the other end of the stack, I have a bunch
> of stuff here that either falls over with DNSSEC or actively lies (AD=1)
> when it's impossible for that to be true.

we need details.

> DNSSEC can provide the security we want with regards to data integrity,
> but I think we're assuming too much of the DNS ecosystem to say that
> it's effective at preventing root zone tampering without actual data to
> support that.
> 
> I could probably re-purpose some of my original root zone emulator work
> to actually test this behavior more in-depth but I think that's a
> separate discussion (esp. with regards to what to test and such).
> Michael
please either continue, or share more detail about prior experiments.

-- 
P Vixie