1 Jul 2011 05:11
Re: Insecure Delegation Proofs
Sean Wells <snwells82 <at> gmail.com>
2011-07-01 03:11:14 GMT
2011-07-01 03:11:14 GMT
Thanks for the clarification.
On Thu, Jun 30, 2011 at 2:30 PM, Brian Dickson <brian.peter.dickson <at> gmail.com> wrote:
No, the attack in question is NSEC3 specific.
The current wording does not indicate that. It talks about both NSEC and NSEC3.
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
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
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.
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
So, it is about protecting secure delegations, not insecure delegations.
And yes, this is rather deep stuff.
Do you mean to say that the last line I quoted means so much
On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells <snwells82 <at> gmail.com> wrote:
> DNSSEC bis updates document states:
> [RFC4035] 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 ?
> dnsext mailing list
> dnsext <at> ietf.org
_______________________________________________ dnsext mailing list dnsext <at> ietf.org https://www.ietf.org/mailman/listinfo/dnsext