Subject: [dnsext] Insecure Delegation Proofs

From: Sean Wells <[email-masked]>
Date: Thu, 30 Jun 2011 12:18:12 -0700

Hi,

DNSSEC bis updates document states:

[RFC4035] Section
5.2<http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2>specifies
that a validator, when proving a

   delegation is not secure, needs to check for the absence of the DS
   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
   needs to check for the presence of the NS bit in the matching NSEC
   (or NSEC3) RR (proving that there is, indeed, a delegation), or
   alternately make sure that the delegation is covered by an NSEC3 RR
   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
   delegations might be used to claim that an existing signed record is
   not signed.

The last sentence is confusing: what is a "spoofed unsigned
delegation" ? Let us say that there are two delegations one of which
is secure.

a.com is secure, so there is a DS record in com

b.com is insecure, so there is a NSEC record for b.com in com with DS,
SOA bits not set but the NS bit set.

I am looking up the DS record for "a.com". The attacker is responding
the NSEC record for b.com (or it was already in my cache). In this
case, the owner name does not match the SNAME (a.com). I thought we
checked the bitmap of the NSEC only if the owner name matches. This
NSEC record might still be accepted depending on what is there in the
"Next domain field". Is this the attack that is being described ?

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Jun 2011 17:30:25 -0400

No, the attack in question is NSEC3 specific.

NSEC3 records, when opt-out is in use, only existence for NS records
that also have a DS (or for non-NS records).

In large, delegation-only zones, like most big TLDs, the ramp-up of
DNSSEC means that those zones will be relatively sparse from a NSEC3
perspective. Most of the delegations will be insecure.

Here, insecure means, "has no DS record".

For an insecure NS RRset, the only DNSSEC records at that node could
be NSEC(3) and the RRSIG(NSEC(3)). If NSEC3 with opt-out is used for
the zone, there will be no signatures at all. If NSEC3 without opt-out
is used, there *will* be an NSEC3 and RRSIG(NSEC3).

The "opt-out" means the "next-hash" is the
"next-hash-of-anything-which-is-not-an-NS-with-no-DS".

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.)

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

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.

The *real* challenge is, if the attacked owner-name has not yet been
fetched into the cache, that it becomes a resource-hit to check for
this (or race condition if the check isn't done - which is why it
needs to be done).

To prevent this NS hijacking, the NS has to be hashed. If the previous
NSEC3 entry before it, does not cover it (i.e. have a next-hash
greater than its hash), subsequent NSEC3 (hashed) RRs need to be
retrieved, until the covering NSEC3 is found. If there is a covering
NSEC3, the insecure and unsigned delegation can be considered
plausible. If there is an NSEC3 whose hash matches the NS, it is
supposed to be a secure delegation, and this is a forgery. This is the
only way to guarantee that there isn't a secure delegation at that
name - something that is strictly necessary to protect the secure
delegations.

So, it is about protecting secure delegations, not insecure delegations.

And yes, this is rather deep stuff.

Brian

On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells <[email-masked]> wrote:
> [RFC4035] Section 5.2 specifies that a validator, when proving a
>
> The last sentence is confusing: what is a "spoofed unsigned delegation" ?
> Let us say that there are two delegations one of which is secure.
>
> b.com is insecure, so there is a NSEC record for b.com in com with DS, SOA
> bits not set but the NS bit set.
>
> I am looking up the DS record for "a.com". The attacker is responding the
> NSEC record for b.com (or it was already in my cache). In this case, the
> owner name does not match the SNAME (a.com). I thought we checked the bitmap
> of the NSEC only if the owner name matches. This NSEC record might still be
> accepted depending on what is there in the "Next domain field". Is this the
> attack that is being described ?
>
> regards,
> Sean
>

---

From: Sean Wells <[email-masked]>
Date: Thu, 30 Jun 2011 20:11:14 -0700

Brian,

Thanks for the clarification.

On Thu, Jun 30, 2011 at 2:30 PM, Brian Dickson <
[email-masked]> wrote:

> The current wording does not indicate that.  It talks about both NSEC and
NSEC3.

> matches an NSEC3 with opt-out, it clearly is a forgery and should be
Section 5.2 in RFC 4035 is about DS RRSets which is what is quoted in
dnssec-bis. The
attack that you are describing here looks different to me.

> And yes, this is rather deep stuff.
Do you mean to say that the last line I quoted means so much :-)

Sean

> the