Subject: nsec3

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Aug 2006 15:52:27 +1000

The nsec3 rdata needs to say how many labels to strip
	off the ownername to get the zone or to put it another
	way.  How many labels hold the hash.

	Currently this is 1 but you don't need that big a hash
	before you exceed 35 bytes (the largest you can encode
	with base32 into a single label).  SHA512 would fit
	happily into 2 labels (48 + 56) if we were to break the
	presentation into multiple of 8 characters.  This would
	also allow for easy decoding as you wouldn't have to
	reassemble the characters to decode.  You could just
	decode each label independently.  

	Mark
-- 
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: Roy Arends <[email-masked]>
Date: Fri, 11 Aug 2006 12:25:01 +0200

>    decode each label independently. 

IIRC, a birthday attack on a hash with 256 bit ouput (like sha256) 
produces a collision with a workfactor of about 2^128. Given the average 
domain name length (a graph with long tail I presume) is about 13 or 14 
octets wide (and not all bits are used in domain names), and the amount of 
names that currently exist are well below the amount of 2^128, I say that 
SHA256, which fits well within 63 octets (base64 encoded) is more than 
strong enough for NSEC3. So I really do not want to introduce this 
multiple label stuff. Is there a need to use very large hash-outputs for 
this application of hashes, considering that the input message size is 
fairly small ? If so, I suggest that multiple label encoding is algorithm 
dependent, and needs to be specified when for instance SHA-384/512 is used 
with NSEC3.

Roy

---

From: David Blacka <[email-masked]>
Date: Fri, 11 Aug 2006 10:38:20 -0400

> 	decode each label independently.  

While you certainly need to know this number, in general it is directly
derived from the hash algorithm.  Since you don't need the information
unless you understand the hash algorithm, I think this is totally fine.

If, in the future, we define a non-constant-length hash for use with
NSEC3, then that definition will have to describe how to determine the
label-length of the hash.  If it had to, it could always add the data to
the 'next hashed ownername' field.  Otherwise, if we define SHA-512 for
use with NSEC3, then that specification will state that the label-length
is 2, perhaps describing the normal split.

However, the current specification does not need to address this now.
Since there is no guarantee that SHA-512 (e.g.) will ever be defined for
use with NSEC3, addressing this issue in the current spec would be
mostly a waste of time.

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