Re: [dnsext] NSEC4

[Miek Gieben <[e-mail]>]

[ Quoting <[e-mail]> at 15:14 on Jan  4 in "Re: [dnsext] NSEC4..." ]
> > This experiment resolves two things:
> > * Reduces the size of the denial of existence response;
> > * Adds Opt-Out to un-hashed names.
> > 
> > We would be grateful if you would like to read this.
> > 
> > Our question is what is the best place to archive this? Re-reading RFC 2026,
> > we are considering to put this on the experimental non-standards track.
> > 
> > Thoughts?
> 
> Interesting!  As Roy points out, we did consider these ideas while working on
> NSEC3, but decided that adding them would make the analysis of NSEC3 even
> harder for the working group, so decided to leave them out.
> 
> I note that with zero hashing, NSEC4 doesn't look exactly like NSEC, as you
> will have NSEC4 records at empty non-terminals.  This is the reason (that is,
> the ability to find a record for every possible closest encloser) that the
> order doesn't have to be DNSSEC canonical name order, and thus could be byte
> order as Ben suggests.

Ah, I see. Because you eliminate empty non-terminals, the depth of the zone
doesn't matter anymore. This would make the algorithm(s) even simpler as
you don't have to switch between hash == 0 and hash == 1.

> Since this is an experiment, why not also experiment with a different type map
> encoding?  I've generally thought that the current encoding isn't typically
> space or computationally optimal.

What are you thinking about?

Other (wild) ideas:

* eliminate the salt
* use a fixed nr of iterations (100 for instance)

Together that would remove the need for an NSEC4PARAM record.

 grtz,

-- 
    Miek

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext