Subject: Re: Proposal to fix NSEC

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 13:52:40 +0100

[email-masked] wrote:

> On Wed, May 19, 2004 at 12:35:44PM +0100, Ben Laurie wrote:
> 
>>I understand this draft comes very late in the day, but it is also my 
>>understanding that it addresses a very crucial issue for registries in 
>>the EU and possibly other regions: their obligation to protect 
>>registrant data.
> 
> 
> 	I guess that I remain unconvinced.
> 	What -registrant- data is stored in the DNS?
> 	In most cases, -registrant- data is stored in
> 	some whois-like database.

NSEC provides an index to whois.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Wed, 19 May 2004 15:40:01 +0200 (CEST)

<hat EDITOR=off>

You're basically bringing back the NO record, with some added jazz:
http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt

We've already done this 3 years ago and I see no reason in bringing this
back. It does not solve a problem (see below). It does not bring anything
new.

A few notes on the spec:

1) You propose an either/or architectural design. No provisioning for bw
   compatibility with nsec, nor signalling that a
   zone/server/resolver/validator/stub supports either/both. You need
   signalling since the nsec and nsec2 are mutually exclusive.
   Unless your NSEC2 proposal absoletes NSEC (bring out the flags for
   flagday), but then its not an 'alternate scheme' like the proposal
   claims. If you're thinking of signalling, there is no room for
   signals in NSEC records (been there done that).

2) The wildcard/closest encounter text is broken. The assumption is that
   even empty (but existing) nodes need a record (EXIST). Which makes them
   NOT EMPTY (since the type EXIST exists). Not to mention the extra
   records you have to put up with: every EXIST type needs a sig plus an
   nsec[2] plus a sig. This assumption is false. Handling wildcards in
   dnssec is complex.

3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since
   you need the NSECINFO record to verify NSEC that proofs NSECINFO
   exist. Thats a circular dependency.

In case you're trying to solve zone walking: Zone walking is still
possible, hash by hash. An offline dictionary attack (remember that the
NSECINFO trick does not work) does the rest. To speed things up, you could
brute-force labels with length up to 5 or 6 characters.

Cheers,

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 09:35:54 -0400

Just did a quick first read -

Is the NSECINFO RR really necessary?  It seems redundant to me and just
another RR/RRSIG combo to be placed in the additional section for a negative
response.  The hash ID could be the first field in the NSEC2 RDATA (just
like in DS, RRSIG, etc) - no need for another record to store that.  The
iterations could be stored there as well, but I don't know how useful it is
to begin with.  Why is it 3 octets long (odd number btw)?  Couldn't it
become a DoS attack vector by a malicious or silly admin setting the number
arbitrarily high?

I also fail to see the use of the salt value in the NSECINFO.  The draft
states it is there to prevent dictionary attacks.  Couldn't an attacker
could just get the salt, and then perform the attack?

I would recommend dropping the NSECINFO RR altogether and move the digest
code and the iterations (though shortening the field to 2 octets) into the
NSEC2 RDATA.  Although I wouldn't mind dropping the iterations field as
well.

Please correct me if I am misreading the NSECINFO RR spec.
Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ben Laurie
> Sent: Wednesday, May 19, 2004 7:36 AM
> To: [email-masked]
> Subject: Proposal to fix NSEC
>
>
> I am sure that this will cause discussions of both a technical and
> political nature. I would like to make it clear from the outset that my
> comments on technical matters are on behalf of Nominet, but political
> comments are my own - I am not empowered by Nominet to discuss policy
> issues on their behalf.
>
> I know that many of you will be at the DNSSEC deployment workshop in SF
> on Sunday - both Geoffrey and I will be there and will be happy to
> discuss this draft with anyone who is interested.
>
> http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt
>
> I will, of course, be submitting this to the I-D editor, but because of
> the nearness of Sunday I thought it best to post it now.
>
> Cheers,
>
> Ben.
>
> --

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2004 00:15:15 +1000

This sort of thing has already been looked at and rejected.
	
	The existing NSEC names also have a useful property in that
	they provide the wildcard name that would otherwise match
	the query name.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 19 May 2004 16:20:53 +0200

Roy,

> back.

With all my respects, the reason is on the table:
the NSEC traversal problem to be fixed within DNS.

Obviously, the notes on the spec you've just submitted have to be 
addressed.

Regards,
Marcos

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 15:40:38 +0100

> http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt

Correct, though I did reinvent it all on my own :-)

>    signals in NSEC records (been there done that).

Surely the returned RRs could simply be either NSEC or NSEC2, and the 
resolver chews whichever it gets?

>    nsec[2] plus a sig. This assumption is false. Handling wildcards in

Why is the assumption false?

>    exist. Thats a circular dependency.

I'm not sure I understand this, but in any case, it has been proposed 
that the NSECINFO record is rolled into NSEC2, which would certainly 
remove circularity, if any exists.

> brute-force labels with length up to 5 or 6 characters.

If we made hashes take, say, 10 ms to compute, then this attack would 
take nearly a year. This is the point, surely? I'd note that simply 
querying for a 6 character domain name only takes that kind of CPU time 
without any attempt to optimise it (i.e. I used dig).

Cheers,

Ben.

---

From: [email-masked]
Date: Wed, 19 May 2004 16:53:49 +0200 (CEST)

> resolver chews whichever it gets?

That means a requirement to implement both. If I just implement either
NSEC or NSEC2 in my resolver, one can be used to downgrade the other.

> Why is the assumption false?

That would be in the dnssec-protocol draft. Empty non-terminals are not
special in DNSSEC.

> without any attempt to optimise it (i.e. I used dig).

I would prefer an offline dictionary attack over a online querying attack
if I did not want to leave to much trails.

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 12:20:28 -0400

I'm trying to fit the EXIST RR into the NSEC response cases in
draft-ietf-dnsext-dnssec-proto.  I think I understand how the NSEC2 and
EXIST combos would work.

Only case 2 (no name, no wildcard) would be affected.  However, could it be
possible to do a EXIST walk of a zone?  If EXIST RRs exist at every
authoritative name in the zone, it is possible for an attacker to do the
same sort of walk just in reverse.

For example:  in the response in the draft, what if an attacker then queries
for "a.b.b.d.e IN A" or similar?  assuming they they get a negative answer
again, a new closest encloser is given (and another point in the namespace).

Scott

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:12:11 +0100

[email-masked] wrote:

> That means a requirement to implement both.

Yes. Or we could deprecate NSEC.

> If I just implement either

I'll come back to this when I've thought about it more.

> if I did not want to leave to much trails.

NSEC makes this equally easy, of course, so I don't really see how this 
is relevant?

Cheers,

Ben.