Subject: Re: [dnsext] Insecure Delegation Proofs

From: "Blacka, David" <[email-masked]>
Date: Fri, 1 Jul 2011 13:28:35 +0000

On Jun 30, 2011, at 3:18 PM, Sean Wells wrote:

> 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 spoofed unsigned delegation is a spoofed response in the form of a referral ("delegation" basically means referral here) without a DS RRset.

> 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 ?

No.  This attack is about obscuring non-delegation names (i.e., and "existing signed record") with the spoofed delegation.  So, imagine you have a signed zone, foo.example.  In that zone, you have an RRset that an attacker wants to change: secure.foo.example/A.  Now, there exists an NSEC record for secure.foo.example:  

  secure.foo.example NSEC secure2.foo.example A NSEC RRSIG

So, when a client asks for secure.foo.example/A, the attacker spoofs a response that looks like this:

  secure.foo.example NS bad-ns1.attacker.example.
  secure.foo.example NS bad-ns2.attacker.example.
  secure.foo.example NSEC secure2.foo.example A NSEC RRSIG
  secure.foo.example RRSIG NSEC ...

That is, the attacker uses the existing NSEC for secure.foo.example.  Note however, that this NSEC record's type map does not have the DS bit set.  So, if you are a naive validator, you might just follow the referral, noting it is insecure (because the DS bit isn't set), but fail to notice that it shouldn't have been a delegation at all.  Hence the advice.

--
David Blacka                          <[email-masked]> 
Principal Engineer      Verisign Infrastructure Engineering

---

From: Sean Wells <[email-masked]>
Date: Fri, 1 Jul 2011 09:49:19 -0700

On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David <[email-masked]> wrote:

> > 5.2<
> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2
> >specifies
> A spoofed unsigned delegation is a spoofed response in the form of a
> referral ("delegation" basically means referral here) without a DS RRset.
>
> No.  This attack is about obscuring non-delegation names (i.e., and
> "existing signed record") with the spoofed delegation.  So, imagine you have
> a signed zone, foo.example.  In that zone, you have an RRset that an
> attacker wants to change: secure.foo.example/A.  Now, there exists an NSEC
> record for secure.foo.example:
>
> That is, the attacker uses the existing NSEC for secure.foo.example.  Note
> however, that this NSEC record's type map does not have the DS bit set.  So,
> if you are a naive validator, you might just follow the referral, noting it
> is insecure (because the DS bit isn't set), but fail to notice that it
> shouldn't have been a delegation at all.  Hence the advice.
>
> Ah! got it. An example always makes it much clearer. This is not even an
attack. I could have looked up a name (that does not exist) earlier that
resulted in the NSEC record in my cache and later when I look up the DS
record, this would answer it.  I suggest we reword the last sentence to make
it clearer.  Something like:

       As every authoritative name in the zone has a valid NSEC record, it
could potentially answer a question
       that is looking for a DS record for any such name. Checking the NS
bit makes sure that this NSEC record
       will not be mistaken for a unsigned delegation.

does that sound right ? I wouldn't even call it an attack. The best way is
to show the above example in the appendix.

thanks
Sean

--

-- 
Sean

---

From: "Blacka, David" <[email-masked]>
Date: Fri, 1 Jul 2011 17:53:02 +0000

> record, this would answer it.  

This is an attack.  The attack is where the bogus NS records come from.

> I suggest we reword the last sentence to make

No, it doesn't sound quite correct.  "it could potentially answer a question that is looking for a DS..." is true, but irrelevant to this case.  The case that this advice is guarding against isn't that specific to qtype.  I'm not going to claim that the current language is as clear as it could be, but this replacement text doesn't quite work, either.

---

From: Sean Wells <[email-masked]>
Date: Fri, 1 Jul 2011 11:33:05 -0700

On Fri, Jul 1, 2011 at 10:53 AM, Blacka, David <[email-masked]> wrote:

> Hmm.. perhaps i am misunderstanding something then. Is it possible for this
to happen even without an attack ? Just by merely using the NSEC record to
answer the question (wrongly) ?

> No, it doesn't sound quite correct.  "it could potentially answer a
> question that is looking for a DS..." is true, but irrelevant to this case.
>  The case that this advice is guarding against isn't that specific to qtype.
>  I'm not going to claim that the current language is as clear as it could
> be, but this replacement text doesn't quite work, either.
>
> Section 5.2 in RFC 4035 is about authenticating referrals where the DS
RRSets are being looked up. Why is this irrelevant to this case ? Perhaps,
this section is more than 5.2 and i am not reading it properly.

Sean