Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains

From: David Blacka <[email-masked]>
Date: Fri, 23 Jun 2006 10:51:01 -0400

On May 31, 2006, at 9:11 AM, Roy Arends wrote:

> ISSUE:
>
> A server must use NSEC3 records from a complete chain. How does it  
> know
> what parameters (salt, iterations, algorithm) to use that belong to a
> complete chain.

I think that the real issue here isn't that there isn't a method for  
learning what parameters to use, but that the currently specified  
method isn't efficient.

To recap the currently specified method:  Implementations are  
expected to find a NSEC3 that corresponds to the zone apex  
(identified by the presence of the SOA bit in the type map), and use  
those parameters.  If there is more than one such NSEC3 record, any  
of them may be chosen.  The means that, if not atomically adding an  
entire new NSEC3 chain to a zone, the zone apex NSEC3 RRset must be  
added last.

However, the practice of having the search for the zone apex NSEC3 RR  
is not efficient to do post zone loading, and to do it during zone  
loading is impractical, or at least distasteful.

So, there are a number of proposed solutions to this issue:

1) Leave the situation as-is.

2) Define a new RR that may be queried at the zone apex that will  
hold the NSEC3 parameters.  This record would be (tentatively) called  
NSEC3-PARAMS.  It would only have value at the zone apex of an NSEC3  
signed zone.

3) Use a special-cased NSEC3 RR named after the zone apex that isn't  
part of the chain, but reflects a completed chain's parameters.  That  
is, an NSEC3 like "example. NSEC3 0 1 100 <salt value> <zero length  
next hashed ownername> <empty type map>".

4) special-case the zone apex NSEC3 RR, naming it after the zone  
apex.  That is, the zone apex NSEC3 RR would be like "example. NSEC3  
0 1 100 <salt value> <lowest ordered hash value in the zone> NS SOA  
DNSKEY NSEC3 RRSIG".  And require this to be the last-added NSEC3,  
just as in the current solution.  This idea was proposed by Mark  
Andrews.

Note that solution #4 could be thought of as a special case of the  
NSEC3 hash calculation function rather than as a special NSEC3 RR.

Solutions 2, 3, and 4 all have the property of having something that  
may be directly looked up by the authoritative server (either primary  
or secondary), which is known to be efficient.

Thoughts?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
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, 23 Jun 2006 13:48:51 -0400

On Jun 23, 2006, at 10:51 AM, David Blacka wrote:

I apparently omitted some critical details about some of these  
solutions.  This is just a followup for clarification.  Not that any  
of it is set in stone.
>
> 3) Use a special-cased NSEC3 RR named after the zone apex that  
> isn't part of the chain, but reflects a completed chain's  
> parameters.  That is, an NSEC3 like "example. NSEC3 0 1 100 <salt  
> value> <zero length next hashed ownername> <empty type map>".

This NSEC3 would a) not be part of the NSEC3 chain, and b) not be  
used to prove the existence or non-existence of anything.  That is,  
it would have to be recognized by the validator as a special NSEC3  
and ignored for proof purposes.

> apex.  That is, the zone apex NSEC3 RR would be like "example.  
> NSEC3 0 1 100 <salt value> <lowest ordered hash value in the zone>  
> NS SOA DNSKEY NSEC3 RRSIG".  And require this to be the last-added  
> NSEC3, just as in the current solution.  This idea was proposed by  
> Mark Andrews.
>

So, the way that I imagine that this would be defined is to say that  
IH(zonename) = <empty>.  That is, the NSEC3 hash calculation over the  
zonename would be defined to be the "null" hash.  This null hash  
would be defined to be first in hash order (i.e., <empty> sorts  
before any other hash value).  The Next Hashed Ownername field for  
this zone apex NSEC3 would have the value of the next hash in hash  
order -- this is the least-valued non-null hash in the zone.  And it  
would deny the existence of names that hashed to values that would  
sort between the null hash and the least-valued hash.  Or, in other  
words, hashes less than the least-valued non-null hash.

The last NSEC3 in hash order would still have the value of the first  
hash in hash order as its Next Hashed Ownername.  However, this would  
always be the null hash.  In wire format, this would be expressed  
with a Hash Length field set to 0.  Some convention would have to be  
used in  presentation format... perhaps "-".

---

From: Ben Laurie <[email-masked]>
Date: Sat, 24 Jun 2006 18:33:57 +0100

David Blacka wrote:
>> A server must use NSEC3 records from a complete chain. How does it know
> learning what parameters to use, but that the currently specified method
> isn't efficient.
> 
> To recap the currently specified method:  Implementations are expected
> to find a NSEC3 that corresponds to the zone apex (identified by the
> presence of the SOA bit in the type map), and use those parameters.  If
> there is more than one such NSEC3 record, any of them may be chosen. 
> The means that, if not atomically adding an entire new NSEC3 chain to a
> zone, the zone apex NSEC3 RRset must be added last.
> 
> However, the practice of having the search for the zone apex NSEC3 RR is
> not efficient to do post zone loading, and to do it during zone loading
> is impractical, or at least distasteful.
> 
> 2) Define a new RR that may be queried at the zone apex that will hold
> the NSEC3 parameters.  This record would be (tentatively) called
> is, an NSEC3 like "example. NSEC3 0 1 100 <salt value> <zero length next
> hashed ownername> <empty type map>".
> 
> 4) special-case the zone apex NSEC3 RR, naming it after the zone apex. 
> That is, the zone apex NSEC3 RR would be like "example. NSEC3 0 1 100
> <salt value> <lowest ordered hash value in the zone> NS SOA DNSKEY NSEC3
> RRSIG".  And require this to be the last-added NSEC3, just as in the
> current solution.  This idea was proposed by Mark Andrews.
> 
> Note that solution #4 could be thought of as a special case of the NSEC3
> hash calculation function rather than as a special NSEC3 RR.
> 
> Solutions 2, 3, and 4 all have the property of having something that may
> be directly looked up by the authoritative server (either primary or
> secondary), which is known to be efficient.

If we're going to change things, then I prefer 2.

3 & 4 both complicate the logic for handling NSEC3 records, for no
obvious reason (to save a type code? really?).

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"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

---

From: David Blacka <[email-masked]>
Date: Mon, 26 Jun 2006 11:20:34 -0400

On Jun 26, 2006, at 7:39 AM, Danny Mayer wrote:

>> solutions.  This is just a followup for clarification.  Not that  
>> any of
>> it is set in stone.
>>>
>> used
>> to prove the existence or non-existence of anything.  That is, it  
>> would
>> have to be recognized by the validator as a special NSEC3 and ignored
>> for proof purposes.
>
> Excuse my ignorance here, but doesn't that mean that an attacker could
> intercept this record replace it with it's own which doesn't have  
> to be
> authentic and cause the validation to fail thereby causing a DOS  
> attack?

I didn't mean to imply that this NSEC3 RR wouldn't be verified when  
it was asked for, just that it would be ignored by validators.

---

From: David Blacka <[email-masked]>
Date: Tue, 27 Jun 2006 07:27:13 -0400

On Jun 27, 2006, at 7:20 AM, Danny Mayer wrote:

>> I didn't mean to imply that this NSEC3 RR wouldn't be verified  
>> when it
>> was asked for, just that it would be ignored by validators.
>>
>
> But I thought that it was the validators that would be asking for it.
> What else needs it?
>

In this case (NSEC3 Issue 18), only authoritative servers need it.

The issue is that a primary or secondary authoritative servers need  
to determine what the NSEC3 parameters are from the zone.  In the  
current versions of the draft (-05 and -06), this is done by  
examining each NSEC3 RR in the zone, looking for the one with the SOA  
bit set.  Some people have pointed out that this sucks.

So, the use case here is a server querying its own data, or a  
secondary querying the primary.