[RSSAC Caucus] Threat Mitigation for the Root Server System

[Michael Casadevall]

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.

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.

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?

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.

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

On 9/30/19 10:54 AM, Joe Abley wrote:
> Hi all,
> 
> I noticed this document today, published last month:
> 
> https://root-servers.org/publications/Threat_Mitigation_For_the_Root_Server_System.pdf
> 
> Although I haven't gone through it in detail and could no doubt come up
> with some comments if I was asked to review it, this looks like a nice
> document. It'd be nice if it was citable and easier to find.
> 
> Is there a reason it wasn't published through the RSSAC process? Or is
> the audience of this document other root server operators, and its
> publication a (welcome!) exercise in transparency? The introduction
> contains the phrase "Root Ops community" but I find that slightly ambiguous.
> 
> I realise I'm crossing the streams a bit by asking here, but it seems
> like the right people will hear the question, and others here might be
> interested in the answer. Also if it's entirely obvious to everybody
> else here why this has happened the resulting public beating with clue
> bats will surely be therapeutic.
> 
> 
> Joe
> 
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
> 
> _______________________________________________
> 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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3106 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20191002/cccda493/pEpkey.asc>