On Wed, 17 Feb 2010, Olaf Kolkman wrote:
Small typos: "enumerated" and "sequential queries"
I am not sure about the "should" in that sentence either. How about "is
accessable through query mechanisms"?
That works for me.
Also, during further editing I have changed the tone of the paragraph a bit: Instead of
"reasons for development" I mention the differences and don't claim them to be
motivations. There are probably many views on the history on how NSEC3 and OPT-OUT came
about and I don;t want to waist time on arguing about those views on history.
Ok.
"at the expense of some deniability"? I feel we need to make it clear
here that there is a trade-of. Opt-out isn't all positive. It has a
price.
I turned that into:
" at the expense of the abillity to cryptographically deny the existence of names in
a specific span."
Ok.
The first reason to deploy NSEC3, prevention of zone enumeration,
makes sense when zone content is not highly structured or trivially
"only makes sense" ?
I think that is right. I cannot come up with occasions whereby those conditions
hold and NSEC3 as a prevention for zone enumeration is still a smart thing to
do.
I meant it has a linguistic change, not a content change. Without the "only"
the setence is a bit difficult to read for me.
5.3. NSEC3 parameters
The NSEC3 hashing includes the FQDN in its uncompressed form. This
"over its uncompressed form"? The hash does not 'include' it.
I overlooked this when I copied the text from P.W. who originally supplied it
:-)
How about "hashing algorithm is performed on the FQDN ..."
Works for me.
5.3.3. NSEC3 Salt
The salt with NSEC3 is not used to increase the work required by an
attacker attacking multiple domains, but as a method to enable
creating a new set of hash values if at some point that might be
required. The salt is used as a "roll over".
I would throw this around.
<pun>
No, you would not, at least you didn't the first time around the initial text
was yours
</pun>
(or am I seriously wrong and acknowledging the wrong person for this
significant contribution?)
It obviously sat too long in your inbox then. But I'm more then happy to
correct myself :)
Don't start saying what the salt is not for,
but say what it is for.
I like this suggestion!
First:
Key rollovers limit the amount of time attackers can spend on
attacking a certain key before it is retired. The salt serves the
same purpose for the hashes, which are independant of the key being
used, and therefor do not change when rolling over a key. Changing
the salt would cause an attacker to lose all precalculated work for
that zone.
I changed the implementation a bit, given the abundant amount of discussion
about key rollovers (which I will try to turn into concrete text) I want to not
make that parallel.
Okay.
delegations within the span. [Editors Note: One could make this
construct more correct by talking about the hashed names and the
hashed span, but I believe that is overkill].
If you think of protecting typosquatting domain spoofs, it might be important
to realise that the span is over hashes, and not over "most domains that
resemble your domain"?
I understand what you mean but how important is it to build this argument
comprehensively?
Ok. I'll leave it up to you. It is not that important.
Remaining dump looked good.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
