[RSSAC Caucus] Threat Mitigation for the Root Server System

[Mukund Sivaraman]

Hi Michael

On Thu, Oct 03, 2019 at 04:45:08AM -0400, Michael Casadevall wrote:
> Replies inline.
> 
> On 10/3/19 3:35 AM, Mukund Sivaraman wrote:
> > Hi Michael
> > 
> > 
> > Isn't "li694-22." a fake domain that only exists on your authoritative
> > server "helium"? And it is unclear if you're also running a fake root
> > zone as in the 1st case you'd described. It's not entirely clear without
> > seeing all the zone's contents and nameserver config.
> > 
> > Anyway, here you're querying helium directly for
> > "hydrogen.li694-22./AAAA". helium is an authoritative for "li694-22." as
> > you've noted - authoritative server algorithm does not perform DNSSEC
> > validation (it is resolver algorithm that does). Basically helium is
> > serving the unsigned "li694-22." zone in this case in isolation. It
> > serves no DNSSEC records because none exist, and returns AA=1.
> > 
> > The nameserver (one that has both authoritative and resolver
> > functionality) prefers to return authoritative data when it is available
> > over cached data.
> > 
> 
> I admit that this isn't a perfect representation. The point of the case
> was to highlight potential abnormalities in handling cases where DNSSEC
> validation should (at least by spec) return SERVFAIL. We're dependent on
> a signed root to prevent anyone from hijacking the root servers either
> via BGP, server compromise, etc.

Nod, but do note that this particular case you've described is not a bug
as validation does not occur. You're directly querying an authority.

> Assuming a compromised root server, an attacker can return AA=1 for
> whatever they like. Assuming a cold cache scenario, a recursive resolver
> might try the following:
> 
> Client -> Resolver: I want A IN for icann.org
> 
> Resolver -> Root Server: icann.org A IN
> 
> Compromised Root: Here's an authoritative answer for icann.org A IN
> 
> Resolver: Oh, it's authoritative, I don't need to worry about DNSSEC.
> 
> Client gets compromised record.

In case of a validating resolver, what you are describing will not
happen as it will try to construct either a secure or insecure path from
the root to the data being validated. A validating resolver has
pre-configured trust anchors for the root zone and expects the root zone
to be signed. It will then attempt to follow a trust chain to whatever
it is validating.

Try to replicate what you're stating as an experiment:

1. Setup authoritative server serving the ICANN root zone.

2. Setup a *separate* validating resolver with the ICANN root zone trust
anchor (should be present by default) that has its root hints configured
to query your authoritative that serves the root zone.

3. Compromise the example.org. domain by adding records directly into
your root zone, and any other changes you want to make to the root zone
such as deleting the .org delegation to facilitate this. (The public
example.org is a signed zone btw.)

4. At the validating resolver, try to query example.org./A and see if
you get an AD=1 answer.

If your root zone does not return a DS record for org. or example.org.,
it has to return a signed proof of non-existence. An attacker will not
be able to create this signature without the root's private
DNSKEY. Similarly for a delegation from org. -> example.org, and so on.
It applies to any compromised nameserver, not just the root servers.

		Mukund