Subject: Re: Removing the SERVFAIL response on hash collisions.

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Aug 2006 15:59:13 -0700

Mark Andrews <[email-masked]> wrote:
> > It's not a matter of won't work. It's a matter of it's extra
> > complexity that's not needed.
> 
> 	SERVFAIL is a BAD response.
> 
> 	SERVFAIL can mean I don't understand EDNS
> 	SERVFAIL can mean I don't understand CD
> 	SERVFAIL can mean I detected a error loading the zone
> 	SERVFAIL can mean I expired
> 
> 	and thats just the list from auth servers.  Some of those SERVFAILs
> 	you can recover from.
>
> 	Returning SERVFAIL is just adding additional complexity to
> 	a already complex part of the answer analysis path.
> 
> 	As a implementer I say that it is actually less complex to
> 	return the variable NSEC than to have to deal with the SERVFAIL.
> 	
> 	Yes, I'm written NSEC3 validator.  I'm well aware of how
> 	much more code I would need to be added to do this.
> 
> 	SERVFAIL would cause you to requery with plain DNS (see the
> 	recovery comment above).  Once you got the plain DNS answer
> 	you would then attempt to prove that the answer was unsecure
> 	which would fail.  You would then try the next nameserver.
> 	Once you had tried all the nameservers for the zone that
> 	you could reach you would then return SERVFAIL.
> 	
> 	We already have to special case how we digest multiple records so
> 	this one is not really any different.
> 
> 	This get a answer through to the validator that it can understand.

But none of this matters because the case in question isn't
going to happen.

-Ekr

--
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: David Blacka <[email-masked]>
Date: Thu, 17 Aug 2006 19:51:54 -0400

Mark Andrews wrote:

>>> 	No one has stated that my solution will not work.  If it won't
>>> 	work please tell me and I'll shutup.

So, what is the response that the server should generate if it has
loaded a zone with a broken NSEC/NSEC3 chain, gets a query for a
nonexistent QNAME, and fails to find the covering NSEC/NSEC3?  (Hint:
BIND 9.3.x returns SERVFAIL...).

So, I see this case as the same case: looks for covering NSEC3, can't
find it.  And a broken NSEC or NSEC3 chain is so mind-bogglingly more
likely than a SHA-1 hash collision.

> 	you could reach you would then return SERVFAIL.

So, what I like about this part of your argument is that your code must
already handle SERVFAIL.  And the behavior you describe sounds OK to me.

In short, using SERVFAIL for this case is (or should be) *zero* extra
code.  Which is about how much code we should devote to this case that
isn't going to happen.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 17 Aug 2006 23:51:35 -0600

... one evening when she had gone down to check her email she happened
to look up at the ceiling, and there she saw a big wooden mallet stuck
in one of the beams, held by a relay that would release if her DNS
server had to deal with an NSEC3 collision.

It must have been there for ages and ages, for it was all covered with
cobwebs; but somehow or another she had never noticed it before, and
at once she began thinking how dangerous it was to have the mallet
just there.

"For," thought she, "supposing him and me was married, and supposing
we was to have a son, and supposing he were to grow up to be a man,
and supposing he were to come down to draw cider like as I'm doing,
and supposing there were a hash collision and the mallet were to fall
on his head and kill him, how dreadful it would be!"

Ormative reference:
http://www.mainlesson.com/display.php?author=steel&book=english&story=sillies

Hilarie

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 21 Aug 2006 11:01:31 -0400

Restart, I lost track of the discussion while reading all the messages
in bulk this morning.

There are two cases of hash-to-name collision possibilities:
	Y    == H(x) (hashed name collides with an existing name)
and 	H(z) == W    (New name collides with a hashed name)

The first one is random and has real low probability, the second is
likely malicious.
If the protocol handling of "collisions" causes "bad side effects"
someone is going to do register new names that collide.

To remove the collision(s) a zone can re-seed the hash parameters,
but in the case of large open registration zones (such as biz., co.uk.
com., de. and org.) someone can do a DOS on the zone.

Zones can protect them self by having a policy that blocks
registration of names that map to current Hash-names.

Alternative is to prefix the Hash-names like is done in IDN names with
an unique prefix and block registrations of that prefix.

What the WG need to determine
	Is current specification sufficient in dealing with
	name/hash-name collision?
	This includes that resolvers/applications are able to get
	the negative answer in a clear manner in ALL cases.

If not
	Should this be handled in-protocol or by-policy ?

If handle-in-protocol
	Propose a solution with suggested text.

	Olafur