Subject: NSEC3 draft comments

From: Edward Lewis <[email-masked]>
Date: Sat, 22 Apr 2006 05:09:03 +0200

Random comments on:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-04.txt

At the bottom of section 7:

    When validating a NOERROR/NODATA response, validators MUST check for
    a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
    (validated) NSEC3 RRset as proof that QNAME exists.  The validator
    MUST also check for an NSEC3 RRset that covers the hash of QNAME as
    proof that QTYPE doesn't exist.

With all the recent haggling over CNAME, well, CNAMEs do count in the 
answer count, so strictly it's not "NoERROR/NoData".  But you can 
have a lookup return negatively without a NSEC(3) for the QNAME.

In 8.1

    In order to prove there exist no RRs for a domain, as well as no
    source of synthesis, an RR must be shown for the closest encloser,
    and non-existence must be shown for all closer labels and for the
    wildcard at the closest encloser.

"for all closer labels"...that is misleading.  You only have to show 
that the domain one label below the CE on the would-be path to the 
sought name is non-existent.

Also, the "wildcard" is not "at" the CE, but is one (asterisk) label below.

I can interpret the paragraph a few different ways, but I think you 
are trying to say "there is no RRset to respond to a query" and not 
"there exist no RRs for a domain."  In reality, no one every checks 
for there being no RRsets at a domain, they check the validity of a 
response.

    This can be done as follows.  If the QNAME in the query is
    omega.alfa.beta.example, and the closest encloser is beta.example
    (the nearest ancestor to omega.alfa.beta.example), then the server
    should return an NSEC3 that demonstrates the nonexistence of
    alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
    *.beta.example, and an NSEC3 that demonstrates the existence of
    beta.example.  This takes between one and three NSEC3 records, since
    a single record can, by chance, prove more than one of these facts.

This is for a name error...the other interpretation of the previous. 
In practice, never try to analyze a query without including the type. 
You can pretty much ignore the class as all classes act the same, but 
types do behave differently.  (DS, anyone?)

It's true that DNS does do a two-part search, name first, then type. 
But you need to consider both to get understand what's in a response.

The section 8.1 name "Proving non-existence" ought to be "Validating 
a Name Error response.

In:

8.4.2.  Second Preimage Requirement Analysis

    A cryptographic hash function has a second-preimage resistance
    property.

Someone needs to explain what that means.  Either in the document or 
via a reference.  (In general, the doc needs to have more references, 
like whenever a term is used that is not defined local to the doc.)

Okay, there is a definition of second-preimage following, but in the 
first sentence, is the meaning that all functions have this?

Maybe this section needs to be restructured to say what the point is 
to an DNS protocol engineer.  Like, it's remotely possible that a 
second name could hash to the same value as the first, and if an 
attacker wants to shutdown access to the first, it uses the second's 
hash to do this.  With different salts and iterations in a zone, 
doesn't this increase the likelyhood of a second-preimage?

Skipping ahead ('cuz I need an example):

    In the above example, the name 'x.w.example' hashes to
    '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might

But above that is

    7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
                               deadbeaf
                               dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
                               MX NSEC3 RRSIG )

So, x.w hashes to the 7nom...a2 value, not the x.w.example.

Multi-label names are in the hash?  Not individual labels?

This means that the NSEC3 for the upper part of a cut point will have 
a different name than the NSEC3 for the lower part of a cut point. 
E.g., for a cutpoint named abc.def.example. will have

    hashvalue1.example. NSEC3 .... NS, no SOA, ...
and
    hashvalue2.abc.def.example. NSEC3 .... NS SOA ...

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
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/>