Re: Insecure Delegation Proofs

Brian,

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

 

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

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

Sean

 

Brian

On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells <snwells82 <at> gmail.com> wrote:
> Hi,
> 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 ?
>
> regards,
> Sean
>

> _______________________________________________
> dnsext mailing list
> dnsext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Insecure Delegation Proofs

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
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Insecure Delegation Proofs

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                          <davidb <at> verisign.com> 
Principal Engineer      Verisign Infrastructure Engineering

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: DNAME?

------- Blind-Carbon-Copy

To: "Jon F." <pikel.m95 <at> gmail.com>
Cc: Timothe Litt <litt <at> acm.org>, bind-users <at> isc.org
From: Mark Andrews <marka <at> isc.org>
References: <45336A86FEAC4E029843F665D31B588A <at> sb.litts.net> <BANLkTim=MAAu1y+XH7yziBMRZNvx30zzFQ <at> mail.gmail.com>
Subject: Re: DNAME?
In-reply-to: Your message of "Thu, 30 Jun 2011 15:10:38 EST."
             <BANLkTim=MAAu1y+XH7yziBMRZNvx30zzFQ <at> mail.gmail.com>
Date: Fri, 01 Jul 2011 10:58:29 +1000

In message <BANLkTim=MAAu1y+XH7yziBMRZNvx30zzFQ <at> mail.gmail.com>, "Jon F." write
s:
> I have a similar set up to that and it works. Have you checked the logs to
> make sure the zone properly loaded? I'm assuming the zone data you posted
> below is from the example.us zone but your first question makes it sound
> like you put it in a seperate zone. That would explain the SERVFAIL if the
> zone data never loaded but the server was authoritative. It does need to be
> in the .us.
> 
> 
> ;; ANSWER SECTION:
> example.com.           60      IN      DNAME   example.net.
> test.example.com.     60      IN      CNAME   test.example.net.
> test.example.net.       60      IN      A       127.0.0.1
> 
> 
> 
> And that's with zone data like this:
> example.com.  IN NS ns1.example.net.
> example.com.   IN NS ns2.example.net.
> example.com.  IN A 10.0.0.1
> example.com. IN DNAME example.net.
> 
> 
> Truthfully I haven't looked at DNAME's in a long time so I'm unsure how to
> do it fully for a domain without adding an A record as well. But what your
> doing works, it's just not very pretty. Someone may have a better way.

There is an outstanding proposals for BNAME.  This would be added
to the parent zone instead of NS records and would synthesis CNAMEs
records for the domain and its children.

This has got bogged down in IETF politics over how to fix idn rather
that be allowed to stand on its own merits.

Mark
- -- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org

------- End of Blind-Carbon-Copy
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Insecure Delegation Proofs

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Insecure Delegation Proofs

On Jul 1, 2011, at 12:49 PM, Sean Wells wrote:

> On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David <davidb <at> verisign.com> wrote:
> 
>> 
>> 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.

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

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

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

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.

--
David Blacka                          <davidb <at> verisign.com> 
Principal Engineer      Verisign Infrastructure Engineering

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Insecure Delegation Proofs

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the DNS Extensions Working Group of the IETF.

	Title           : Signaling Cryptographic Algorithm Understanding in DNSSEC
	Author(s)       : Steve Crocker
                          Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-signal-02.txt
	Pages           : 8
	Date            : 2011-07-06

   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be generated using
   different algorithms.  This draft sets out to specify a way for
   validating end-system resolvers to signal to a server which
   cryptographic algorithms they support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Fwd: I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt

An updated version of the algo-signal draft to address the issues in WGLC.  Specific changes:

1.  Changed the wording in 3.4.1 to remove the RFC2119 wording on setting the DO bit.  

2. Changed section 4 wording to indicate DNS proxy systems and added a ref to RFC 5625.

3. fixed some typos and minor wording changes to stress that the DAU option is for signaling only and does not
specify any change to how servers construct a response.

Scott

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Date: July 6, 2011 9:50:12 AM EDT
> To: i-d-announce <at> ietf.org
> Cc: dnsext <at> ietf.org
> Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the DNS Extensions Working Group of the IETF.
> 
> 	Title           : Signaling Cryptographic Algorithm Understanding in DNSSEC
> 	Author(s)       : Steve Crocker
>                          Scott Rose
> 	Filename        : draft-ietf-dnsext-dnssec-algo-signal-02.txt
> 	Pages           : 8
> 	Date            : 2011-07-06
> 
>   The DNS Security Extensions (DNSSEC) were developed to provide origin
>   authentication and integrity protection for DNS data by using digital
>   signatures.  These digital signatures can be generated using
>   different algorithms.  This draft sets out to specify a way for
>   validating end-system resolvers to signal to a server which
>   cryptographic algorithms they support.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt
> _______________________________________________
> dnsext mailing list
> dnsext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

WGLC: Elliptic Curve DSA

Dear Colleagues

This message starts a Working Group Last Call for
"Elliptic Curve DSA for DNSSEC" located at
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt
This document is on Standards track.

This WGLC will conclude on midnight on July 21'th UTC.

Please review the document and sent a statement that you reviewed the
document.  If the review raises any issues, please note what they are.
Remember that we need a minimum of 5 reviewers.

     Olafur & Andrew
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext