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_...
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@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.