Subject: nsec3 and unknown hash algorithms

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Aug 2006 17:54:40 +1000

How, using the NSEC3 only, can I workout whether to
	to ignore a NSEC3, with a unknown hash algorithm, or
	not? 

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

--
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: Wouter Wijngaards <[email-masked]>
Date: Tue, 22 Aug 2006 10:28:07 +0200

> 	to ignore a NSEC3, with a unknown hash algorithm, or

I don't understand, the draft says that auth-servers must refuse to load
 a zone with only nsec3-unknown-hash-algorithm after zone transfer. And
the draft says that resolvers should ignore all nsec3 records with
unknown hash algorithms. And if all nsec3s have an unknown hash
algorithm, then the response is to be considered insecure. So you have
to always ignore the nsec3.

What I don't understand is why you would want to not ignore the nsec3
with a unknown hash algorithm.

Though if you are processing a noerror-and-data response, the RRSIG on
the data can validate, and even without the nsec3s that may be good
enough for you to consider the data to be secure.

ciao,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Aug 2006 22:32:11 +1000

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:

	You only want to ignore them if they are from the same or
	parent zone as the answer you are trying to verify.   They also
	need to be from a zone at or below the secure entry point in the
	validators config.

	There is no way to reliable extra the zone from the NSEC3 for
	a unknown hash algorithm.
 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFE6sAXkDLqNwOhpPgRAkY6AJ0TR6HuVXkrICcKCDnwMnDOmiOy0gCfQ2QQ
> ksIcwSYkuLts7uF5oJ6NV94=
> =eCW4
> -----END PGP SIGNATURE-----

---

From: David Blacka <[email-masked]>
Date: Tue, 22 Aug 2006 10:11:45 -0400

>> 	a unknown hash algorithm.

Well, you should be able to check that the owner name is a descendant of
the zone you think you are in.  Or you could just use the signer name
from the RRSIG.

The issue here isn't the ignoring, it is the rule that a response with
all unknown hash algorithm NSEC3 should be considered INSECURE.
(Otherwise, ignoring the NSEC3s would just lead to a BOGUS result).

So what Mark is worried about is an attacker using signed, unknown hash
algorithm NSEC3 RRs from a different zone as the means to a downgrade
attack.  This is a good point, and this issue isn't adequately addressed
in the draft.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Aug 2006 00:33:44 +1000

> with a unknown hash algorithm.

	I'd actually like to be able to.  The problem is that currently
	you have to verify them.  Workout if they are applicable.  If
	they are applicable you then need to treat the zone as unsecure.

	Is

	4TV65B46C1JFFTTCRRA3FDM90NTMCT1J.TVOV42ISI667L761OGKFF9NU78ELDHGFVM2NUVHU.7JBJ35Q7.NET NSEC 0 20 0 - QT41E5SOUMJJQKHOQF2ECTJBR080PQV6KCM6MHKAHABMKV3MNBNLDJUIA30OLB0JTNGOVEMA A SOA NS

	applicable to 42ISI667L761O.7JBJ35Q7.NET?

	I don't know?  I could make a guess based on the hash length but
	there is nothing in the current spec to tell me how to treat this
	NSEC3 record.

	I need a nsec3 spec that is future proof.  What we have now isn't
	future proof.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Aug 2006 00:43:11 +1000

> the zone you think you are in.

	Which you often don't have when you are validating a response. 

>  Or you could just use the signer name from the RRSIG.

	Which means that you need to track which RRSIG actually verified
	the RRset and cache it.