Subject: Re: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)

From: Brian Dickson <[email-masked]>
Date: Mon, 10 Nov 2014 18:49:39 -0800

Paul Vixie wrote:

> because right now the people who do this have to pirate the address space
> of root name servers, and they have to do it for all of our addresses.
> under this proposal, there would be no piracy required, and there would
> only be two address blocks per stack (two for v4, two for v6) to do it for.

Actually, I don't believe this is the case.

Here's why:
- the root servers are authoritative for "root-servers.net"
- root-servers.net is unsigned
- the root zone is signed
- the glue for the root zone (like all other glue) is not signed (or even
signable)

So, alternate root zone hints files, and alternate versions of root zones,
can be created and served, with only the NAMES of the root servers signed,
protected, and unmutable.

The addresses associated with those names ( [a-m].root-servers.net ) are
replaceable in a way which is undetectable and unprotected by DNSSEC.

Thus, there is no need to hijack BGP routes. There is not even a
requirement that 13 unique addresses be used. The same single address could
be served up for all 13 entries (as glue data).

In that respect, arguably the proposal is kind of moot.

(On the other hand, I think this demonstrates the weakness of not pushing
for splitting the original "NS" into two different RR types (parent NS and
child NS), and making the authority for each the respective owner, and
having the owners signing them.)

I'd prefer to live in a world where BGP hijacking WAS necessary, and where
the root server addresses were signed, authoritatively served from within
the root zone directly (with no delegations).

E.g. change the names of the root servers to literally "a." through "m.",
and being in the root zone itself, have signed A/AAAA records served
(either in response to queries for their addresses, or as Additional data
with signatures when DO is set).

Any chance of that happening, in this century?

Brian

---

From: Ralf Weber <[email-masked]>
Date: Mon, 10 Nov 2014 17:16:57 -1000

Moin!

> On 10 Nov 2014, at 16:49, Brian Dickson <[email-masked]> wrote:
> 
> The addresses associated with those names ( [a-m].root-servers.net ) are replaceable in a way which is undetectable and unprotected by DNSSEC.
> 
> Thus, there is no need to hijack BGP routes. There is not even a requirement that 13 unique addresses be used. The same single address could be served up for all 13 entries (as glue data).
> 
> (On the other hand, I think this demonstrates the weakness of not pushing for splitting the original "NS" into two different RR types (parent NS and child NS), and making the authority for each the respective owner, and having the owners signing them.)
> 
> I'd prefer to live in a world where BGP hijacking WAS necessary, and where the root server addresses were signed, authoritatively served from within the root zone directly (with no delegations).
Why. What matters if the content of the root zone aka the delegations to TLDs. All of these are signed if they use DNSSEC and that's the case for most TLDs. It really doesn't matter where the root zone is served from, quite the opposite. IMHO we should spread it as widely as possible right into the recursive resolvers.

With DNSSEC any modification (malicious or not) can be detected so the actual packet origin doesn't matter. The data origin/authenticity is what we care about.

So long
-Ralf
---
Ralf Weber 
e: [email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Mon, 10 Nov 2014 22:11:25 -0800

On Mon, Nov 10, 2014 at 7:16 PM, Ralf Weber <[email-masked]> wrote:

> > The addresses associated with those names ( [a-m].root-servers.net )
> are replaceable in a way which is undetectable and unprotected by DNSSEC.
> >
>
>
> With DNSSEC any modification (malicious or not) can be detected so the
> actual packet origin doesn't matter. The data origin/authenticity is what
> we care about.
>

This is true ONLY for DNSSEC-protected data, and then only to the degree
that confidentiality is not an issue.

For example, by substituting the address glue for the root servers, an
attacker could then MitM all subsequent DNS traffic, by providing
delegation glue for nameservers that point at (other) attacker-controlled
machines. At a minimum, the attacker would see all the DNS queries and
answers. And, for any names not DNSSEC-protected, the attacker could then
trivially supply forged answers.

Given the relatively low penetration rate in sizeable portions of the
namespace, this is indeed something worth worrying about.

And, it helps give motivation for removing any and all impediments to wide
deployment of DNSSEC, on resolvers, clients, and
registrants/registrars/registries.

Regards,
Brian

---

From: Ralf Weber <[email-masked]>
Date: Tue, 11 Nov 2014 09:56:58 -1000

Moin!

> On 10 Nov 2014, at 20:11, Brian Dickson <[email-masked]> wrote:
> This is true ONLY for DNSSEC-protected data, and then only to the degree that confidentiality is not an issue.
> 
> For example, by substituting the address glue for the root servers, an attacker could then MitM all subsequent DNS traffic, by providing delegation glue for nameservers that point at (other) attacker-controlled machines. At a minimum, the attacker would see all the DNS queries and answers. And, for any names not DNSSEC-protected, the attacker could then trivially supply forged answers.
So you would have to be man in the middle on the priming query as otherwise these addresses are ignored. Pretty hard if you are running on 127.0.0.1 or nearby the resolver. Now if you stub without priming which is what Warrens draft suggest this attack is impossible as you are hard coding the IP you ask the first iterative query and only look and follow the referral, which at some points includes validating the signature over the DS record that points to the DNSKEY of the TLD.

> Given the relatively low penetration rate in sizeable portions of the namespace, this is indeed something worth worrying about.
But if that is a problem worth worrying it already exist today as your path to the root server is longer now. It is not made worse by this or Warrens proposal.

So long
-Ralf