Subject: Re: number games. (really NSEC2 vs dictionary attacks)

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jun 2004 15:40:34 +0000

> > ...
> > local hash functions is a wee bit more efficient then online querying
> 
> Also take into consideration that a random non-existant response will
> contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid
> names.  An attacker may get a large portion of the (hashed) namespace by
> doing random queries like this without too much effort.  They still need to
> do the dictionary attack however.

as was discussed in the kerberos community a few years ago, offline dictionary
attacks -- where the victim has no idea how much effort is being expended and
things like botnets and distributed.net can come into play -- are dangerous.

> I also have a question about the salt field in the original spec.  I still
> am not sure it is useful.  A determined attacker will just take the salt
> value anyway and use that.  Why not just have the hash be the FQDN?  For
> example:  Hash(www.example.com).example.com.

that looks really cool, but it doesn't change the danger.  home pee cees now
have 4GHz processors, and it's still doubling every once in a while.  apple's
"altivec" may be the first mass production example of what's about to be a
very popular kind of technology -- maybe a million vector processors running
insecure operating systems on 24x7 DSL lines is the right threat model here.

> Mainly I'm thinking of ways to reduce the need for the NSECINFO RR and move
> the remaining fields (hash algo and iterations) into the NSEC2 RR.

there's a lot of room to clean this up, but it's not on the critical path to
getting dnssec-bis out the door.  i'm enjoying the thread, but the goals of
the WG wrt dnssec are still (1) measure/prove the dnssec-bis document/protocol
quality; and (2) select one or several ways that -bis can become -ter later.

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Jun 2004 16:41:34 +0000

> How about adding text:

i'm uncomfortable with this case-by-case discussion of rrtypes above a
delegation point.  the way the base dns protocol works is that "an NS
RRset at a zone bottom is (a) nonauthoritative and (b) cannot be
usefully accompanied by any other data."  the way rfc2535 changed this
is hard to describe, and now irrelevant.  the way dnssec-bis changed
this is to add two words "except NSEC and DS" to (b) above.

we do not need to mention that DNSKEY shouldn't appear "above the cut",
and if we do then some future reader of the document might incorrectly
infer that since we said this about DNSKEY but didn't say it about A or
TXT or MX, that "the intent of the framers" is that all rrtypes not
described as ``can't appear above the cut'' must in fact be able to
appear above the cut."  that is NOT our intent, so let's not imply it!

can we just explain that

    While DNSSEC-BIS specifies the placement of two new RRsets, NSEC and DS,
    in the parent zone above zone cuts, this is an exception to the general
    prohibition against putting data in the parent zone above a zone cut, and
    the general prohibition remains in effect.  See RFC 1034.

and not go into this on an rrtype-by-rrtype basis?

re:

> DNSKEY RRs appearing above the delegation point are non-authoritative
> cannot be used for validation of RRSIGs by validators unless the
> DNSKEY RRs also meet the requirments in Section 5.
> 
> - or change the "cannot" to SHOULD NOT/MUST NOT to make it more forceful?
> 
> Scott
> 
> > Sorry - should have also said:
> >
> > This needs to be in the form of what the resolver does when it sees weird
> > things, rather than a prohibition on the server putting the things
> > there.  While its true the parent should sign these, from time to time
> > someone will and we need to be clear on what the behavior of the resolver
> > needs to be.
> >
> > >> > Drop sentence from section 2.1:
> > >> >
> > >> >   DNSKEY RRs MUST NOT appear at delegation points.
> > >> >
> > >>
> > >>This seems to be in the spirit of the Q-8 and Q-11.
> > >>
> > >>I would replace the above sentence with something like:
> > >>
> > >>    DNSKEY RRs appearing above the delegation point are
> > >>    non-authoritative.
> > >
> > >DNSKEY RRs appearing above the delegation points are non-authoritative,
> > >extraneous and MUST NOT be used to determine the validity of any DNSSEC
> > >trust chain.
> > >
> > >>Maybe even make it explicit that the above means that one is dealing
> > >>with glue and the DNSKEY RRs should not be signed by the parent.