On Fri, 29 Oct 2004, Ben Laurie wrote:
If opt-in is dropped, then (from memory), the only remaining point
is whether hashing is done per-label or over the whole name.
In San Diego, I did presentation comparing the two NSEC++ proposals,
but I don't think a summary ever made it to the list (sorry about
that). The slides are in the meeting proceedings:
http://www.ietf.org/proceedings/04aug/slides/dnsext-7.pdf
To summarize, in addition to the choice of whether hashing is
per-label or not [1], the two proposals had three "options": opt-in,
allowing hash iterations, and defining a null hash function. I think
we can pick and choose among these, and I think both the iteration
option and the null hash option are pretty trivial, but I don't recall
us making any decisions about them.
In my presentation, I also faulted both proposals for not describing
how to change hash functions or salts (or number of iterations)
and
for not going into enough detail about wildcard processing. Both of
those need to be addressed. I also worried about hash collisions,
though people keep trying to convince me that the probabilities of a
collision can be made vanishingly small. I'd rather see a mechanism
for rolling (or allowing for coexistence of multiple) hashs and/or
salts, but I'm willing to drop the collision concern.