[dnssec-deployment] Question Regarding DNSSEC (fwd)

[James M Galvin]

Is this what Steve Bellovin was discussing at the DNSEXT meeting this
past IETF, or is it at least similar?

Jim



---------- Forwarded message ----------
Date: Tue, 27 Apr 2004 19:46:23 +0000
From: Paul Vixie <paul at vix.com>
To: DNSSEC deployment <dnssec-deployment at shinkuro.com>
Subject: Re: [dnssec-deployment] Question Regarding DNSSEC

> > > For large zones, nsec walking is a very big issue
> >
> > Full agreement here.  This problem is underrated, IMHO.  ...
>
> I've said it before, so I'll simply add a "me too" here.

yow.  i guess that's a quorum on this topic.  but let's be sure we're all
talking about the same thing.  an NSEC RR is necessary, in the current design
of dnssec (which is the fourth major design in the ten years we've been
playing this game), to prove that a name does not exist, and to prove that
all-but-specified rrsets at an existing name, do not exist.  its fields are:

		ownername (class) NSEC targetname ( typelist )

since each NSEC RRset is cryptoauthentic, the existence of an NSEC is "proof"
of two assertions:

		1. for (ownername < x < targetname), name x does not exist
		2. at ownername, only rrset types in typelist exist

the important part is what's omitted.  there's no assertion that
targetname exists.  in NSEC chainwalking, targetname has to exist, and
becomes part of a "linked list of existing names".  but targetname only
happens to exist, today, because the various DNSSEC implementations
generate NSECs at "zone signing" time and then answer with precomputed
NSECs whenever they're about to send back an RCODE=3 ("NXDOMAIN") response.

a degenerate case would allow (ownername = targetname) in which case no
name-nonexistence span is asserted.

another degenerate case would be a typelist including only NSEC itself,
in which case neither ownername nor targetname meaningfully "exist."

combining these, it's possible to include a proof in an RCODE=3 response
that is generated in real time rather than generated at zone signing time.
this would require extensive hardware crypto since software is much slower
at generating signatures on simulated NSEC rrsets than "the wire" would be
at delivering new queries for nonexistent names.  (this is sometimes called
a CPU DoS attack.)

therefore, the current (fourth major) design of DNSSEC does not actually
require that you make your zone vulnerable to "NSEC walking".  and speaking
for ISC, i hope that interested parties will decide to fund better DNSSEC
implementation efforts to close this vulnerability.  (ISC's DNSSEC effort
is "internally funded" at this time, and our resources are limited, but we
know DNSSEC is important, and hope springs eternal that others will think
likewise someday and that those others will bring some money with them.)

anyway, the registries have some options beyond "don't deploy DNSSEC
because the NSEC walking problem is too awful to live with."  BIND
9.3.0beta talks about something called "DNSSEC Lookaside Validation"
which, while not well documented as yet, also shows some promise at
avoiding "the NSEC walking problem."  one could almost draw the conclusion
that these deployment barriers have been carefully analyzed by others over
a period of years and that solutions will be developed and that deployment
will NOT be slowed or prevented, "some hell or high water."

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <dnssec-deployment at shinkuro.com>.
To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
To switch to the DIGEST mode, E-mail to <dnssec-deployment-digest at shinkuro.com>
To switch to the INDEX mode, E-mail to <dnssec-deployment-index at shinkuro.com>
Send administrative queries to  <dnssec-deployment-request at shinkuro.com>