Re: draft-arends-dnsnr-00

[Roy Arends <[e-mail]>]

On Tue, 27 Jul 2004, Samuel Weiler wrote:

> Thanks for the clarifications.  And thanks for your note on Monday
> comparing NSEC2 and NSEC3.  I'm looking forward to reading -01.
>
> Perhaps the reason I was confused starts with this line in Section 2:
>
>    The DNSNR resource record lists RR types present at the DNSNR RR's
>    ownername.

Ah yes, I tried to generalise. I will rewrite that.

> If the DNSNR owner name is a hash, this isn't quite true.  And this
> line in 2.1.4:
>
>    The value of the Next Owner Name field in the
>    last DNSNR record in the zone is the name of the zone apex (the
>    ownername of the zone's SOA RR).
>
> Which implies that you're retaining the old (non-hashed) canonical
> ordering.

Yes. The paragraph you are referring to starts with "If the Hash Function
Field has value 0,", which means that the ownernames of the NSEC3 records
are not hashed.

> Perhaps this doc needs the same thing I suggested for
> NSEC2, a high-level description of what's changing.  It needs to be
> very, very explicit that you may or may not have NSEC3's at the same
> names as other records.

Okay.

> Like his doc, there needs to be a discussion
> of what happens when the salt or hash algorithms change.

The revision will be similar to dnssec-bis-proto

 o Zone signing
   - Including NSEC3 RRs in a Zone
   - Example of a Secure Zone
 o Serving
   - Including NSEC3 RRs In a Response
   - Example DNSSEC-ter Responses
 o Resolving
   - Response Caching
 o Authenticating DNS Responses
   - Authenticated Denial of Existence
   - Authentication Example

> > Per-span, I'll make that clear.
>
> You need to be explicit, then, that it's per-span in the (possibly)
> hashed namespace, which means the names covered by a single NSEC3 will
> vary depending on the hash algorithm and salt chosen.  If you have
> some spans opt-in and some opt-out, this means the names in the
> "protected" space will vary depending on the salt and hash algorithm.
> This is a very interesting property, though it makes my head spin.

My apologies, it is Per-Zone. Per-span does not work. Due to the pre-image
resistence of hash-functions it would be hard to augur which span covers
what qname, therefor the property needs to be applied to all NSEC3 in a
zone, not independantly. Plain ownernames (as opposed to hashed owner
names) do not have pre-image resistance, so the requirement could be
relaxed here, but then this proposal becomes very complex.

I'll make it explicitly "Per-Zone".

> Thinking about "perfect hash functions" from the land of data
> structures is leading me to wonder if one can create a hash algorithm
> and salt such that you can force a set of names (ie. all of the
> unsecured delegations in your zone) to be in one span, so you can mark
> only that one span as opt-in yet secure the rest of the zone.

This is very hard, due to the same issues as I've written above. A
workaround can be to query twice, but that is very ugly. It is far more
easy to declare it per-zone and be done with. If that would impose
irreconcilable constraints to a security policy, then the alternative
would be to not use it at all.

> > > Also, the presentation format of the hash value is inconsistent
> > > between 2.1.2 (third paragraph) and 2.2.
> >
> > I don't see that, could you give me a pointer ?
>
> I think I misread this the first time, and then I didn't even
> correctly describe the problem I thought I saw.  (I thought 2.1.2
> said the salt was presented in base32.)  In any case, the third
> paragraph of 2.1.2 is still unclear.  It reads as:
>
> 	... the hash function .... is presented by a base32 value.
>
> I think you mean that the owner name and next owner name fields are in
> base32, but that's not what the sentence says.  (Since the hash
> function field is an unsigned integer, per 2.2.)

Ah, thanks. Will fix.

> Again, I'm looking forward to seeing the next version.  I'd also
> really like to see a discussion of wildcard handling, as Ben
> suggested.

The wildcard handling in Bens draft is needed because NSEC2 obscures
empty-non-terminals, and therefor introduces EXIST. That makes handling of
wildcards different then current NSEC. NSEC3 handles wildcard exactly as
NSEC does, since empty non-terminals are not obscured. I will put in a
note saying that, but I do not see the purpose of discussing wildcard
handling when it is exactly as NSEC.

Roy

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>