Subject: Re: [dnsext] Insecure Delegation Proofs

From: Lutz Donnerhacke <[email-masked]>
Date: Fri, 1 Jul 2011 09:25:45 +0200

You wrote:
> Since the insecure NS records are not signed (at all!), they can be spoofed.
> (IMHO, the lack of signature on NS (without DS) is uncool in the
> extreme. Having NS RRSIGs, even though they are not authoritative,
> would still have been compatible with opt-out. But that ship has
> sailed, as they say.)

Glue is never signed, because it's impossible to distinguish algorithmically
between an answer from the zone or its parent zone. It is possible to copy
the glue records from the authoritive servers and include those (deeper)
signed records as glue, but the validator can't really make benefit from.

That's why the key material is distributed in two record types:
 DNSKEY contained by the zone
 DS containted by the parent zone

A zone is not allowed to sign or respond with its own DS records and a
parent zone is not allowed to sign or respond with the child DNSKEY records.

Moving a special record of the zone into the parent allows the resolver to
distinguish the various delegation levels and complete the delegation chain
by asking for DS records explicitly (to overcome the grandparent problem).

Consequently the RRSIG of a response from the parent zone can only cover the
DS (because it's authoritive) and not the NS (because it's glue). OTOH the
RRSIG of a response from the child zone has to cover at least the DNSKEY,
NS, and SOA records (because they are authoritive and needed for a correct
setup) and never DS (because it's not in scope).

For the usual historical remarks, let me point out, that the early DNSSEC
idea was to put the whole key material into the parent zone (KEY with SEP
bit) and the client zone (KEY without SEP bit).

> The attack is, to over-write a *signed* NS (with DS), by an unsigned
> NS (with no DS or any other DNSSEC record).

Sorry, I do not get it. Why should an unsigned NS record be accepted at all?
If the zone y.z is signed, there is either an signed DS for x.y.z or an
NSEC(3) record covering x.y.z. Only in this case the response from the
parent is correct. And even in this case the attacker can simply modify the
NS (glue) entries on the fly.

> The defense is, to check the hash of any unsigned NS, and if it
> matches an NSEC3 with opt-out, it clearly is a forgery and should be
> discarded.

Why? That's a legitim response from a parent zone.

> To prevent this NS hijacking, the NS has to be hashed.

There is no way to prevent glue modifications at all.

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext