Subject: Re: NSEC3 Issue 23: dealing with unknown hashes

From: Roy Arends <[email-masked]>
Date: Fri, 25 Aug 2006 10:10:52 +0200

[email-masked] wrote on 08/25/2006 02:50:41 AM:

> > NSEC3 Issue 23:
> > 
> > (see also http://www.nsec3.org/cgi-bin/trac.cgi/ticket/45 )
> > 
> > If a validator ignores an NSEC3 resource record because it contains an 

> > unknown hash algorithm and subsequently treat a dnssec/nsec3 response 
as 
> > 'unsigned', the validator must check that the NSEC3 record came from 
the 
> > proper zone.
> > 
> > This check needs to be done to avoid a replay of some arbitrary NSEC3 
with 
> > 
> > an unknown hash algorithm, that happens to be signed with a key that 
the 
> > validator trusts. A successful replay can lead to a downgrade attack. 
> > 
> > The ownername of the NSEC3 record contains the hash value, prepended 
to 
> > the zone name. Since we want the NSEC3 record to be future proof, we 
have 
> > to allow digests to be longer than the maximum label size, and so, a 
> > future hash algorithm might have a digest that is presented over 
multiple 
> > labels.
> > 
> > We can therefor not safely assume that the first label contains the 
hash 
> > value, and the rest of the name is the zone name.
> > 
> > So, we need to find a way to discover the zone that the NSEC3 is from.
> > 
> > We have several approaches for this, described here in no particular 
> > order:
> > 
> > 1) it is possible to calculate the number of labels that contains the 
hash 
> > from the hash length field. 
> > 
> > The hash length field contains the length of the hash of the Next 
Hashed 
> > Owner Name field. This length is in octets. The following formula 
> > determines the amount of labels used for the hash, and indicates that 
the 
> > rest of the labels contain the zone.
> 
> > Let L be the value of the hash length field
> > 
> > Then labelcount = 1+((L*8)/315)
> > 
> > This approach assumes that all hash outputs for this single (unknown) 
> > algorithm have the same length, since the hash length field applies to 
the 
> > 
> > Next Hashed Ownername, not to the Owner Name of the NSEC3 record. 
Hence, 
> > an Identity Hash function, a function with variable length output, can 
not 
> > be easily defined this way.
> > 
> > 2) it is possible to use the Signer's Name field of the RRSIG record 
that 
> > accompanies this NSEC3 record. The drawback is that the validator, 
while 
> > checking the applicability of the NSEC3 record, must have knowledge of 
the 
> > 
> > RRSIG at that stage. Note that the validator _has_ to check the 
validity 
> > of the signature anyway if it decides to treat a response as insecure 
due 
> > to an unknown hash algorithm. 
> > 
> > 3) Add a 'Zone labels field' to the rdata field that indicates of how 
many 
> > labels the zone consists of, and hence, use that as a mask for the 
> > ownername of the NSEC3 record to determine the zone name. The drawback 

> > here is that the NSEC3 rdata is changed Yet Again. 
> > 
> > 4) drop the 'unknown hash' methodology alltogether. This means that if 
an 
> > unknown hash is encountered, it is discarded. When the validator tries 
to 
> > validate the response, it ignores unknown hash NSEC3's and will treat 
the 
> > response as bogus. The drawback is that it will be hard to introduce 
new 
> > hash algorithms, unknown to a deployed base. The penalty is that zones 

> > using this new hash algorithm will be treated as bogus, thus 
> > unresolveable, for the deployed base.
> 
>    Not really.  We just specify that if you want to use the new hash
>    algorithm then you need to use specific key algorithms. 

When a new hash-algorithm is introduced, it might be because an old 
hash-algorithm is broken. In that case, a new key-algorithm must be used 
as well, if the signing used that same broken hash-algorithm. So this 
makes sense. 
Furthermore we already understand the semantics of this, it is similar to 
rolling from NSEC to NSEC3. 

> > 5) truncate all hash outputs over 315 bits to 315 bits so it will 
always 
> > fit in a single label. The drawback here is that the 2nd-preimage 
> > resistance of a hash function is then restricted to 2^315, and thus 
less 
> > futureproof.
> > 
> > Note, the number 315 is the amount of significant bits of a base32 
decoded 
> > 
> > maximum length label (5 * 63)
> 
>    280 is the maximum number of bits that can be base32 encoded into
>    a single label.  63/8 => 7 base32 blocks, 7*5*8 => 280 bits.

yes
 
>   6) Remove algorithm agility.

Roy

--
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: Fri, 25 Aug 2006 12:45:40 -0400

>> 4) drop the 'unknown hash' methodology alltogether. This means that if an 
>> unknown hash is encountered, it is discarded. When the validator tries to 
>> validate the response, it ignores unknown hash NSEC3's and will treat the 
>> response as bogus. The drawback is that it will be hard to introduce new 

The referred to "'unknown hash' methodology" is to return an INSECURE
result when all of the NSEC3s are using an unknown hash algorithm.  So
dropping means that you would need to do a key algorithm roll (or
equivalent) in order to get the desired behavior.

>> 5) truncate all hash outputs over 315 bits to 315 bits so it will always 
>> resistance of a hash function is then restricted to 2^315, and thus less 
>> futureproof.
>>
>> Note, the number 315 is the amount of significant bits of a base32 decoded 
>>

By this I assume that you are suggesting (as an option) essentially
fixing the hash algorithm field to "1", or removing the hash algorithm
field altogether.  That is, if a new algorithm is desired, then a new RR
 type will have to be defined.  Correct?

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