Subject: Re: handling of additional data (fwd)

From: Paul Vixie <[email-masked]>
Date: Thu, 13 May 2004 19:36:30 +0000

> >	It means that older nameservers didn't have restrictions
> >	and it ended up being a management nightmare.  Been there,
> >	done that, don't want to go there again.
> 
> Was there ever documentation of that?

not in the form of an FYI or BCP, and it appears to have been left out
of 2181/2182 as well, but it was discussed on the old dns-security@TIS
mailing list back in april of 1994.

> >>  > 	Stricter rules were needed.
> 
> Did any of these ever get put into a document?
> 
> I don't doubt your words, I just want to know if the lessons have been
> recorded.

here you go:

--------

From: [email-masked] (Paul A Vixie)
Newsgroups: local.mail.dns.security
Subject: Re: DNS security draft
Date: 20 Apr 94 14:47:20
Organization: Vixie Enterprises
Lines: 27
Distribution: local
Message-ID: <[email-masked]>
References: <[email-masked]>
NNTP-Posting-Host: office.home.vix.com
In-reply-to: [email-masked]'s message of 20 Apr 1994 10:03:42 -0700

>What it boils down to seems to be this.  Any resolver or server which
>preserves the distinction between authoritative and non-authoritative
>(example: glue) data better than BIND does will break the proposed
>scheme of cross-authentication of zones.
>
>[...]

BIND as of 4.9 preserves the distinction between authoritative and
nonauthoritative data; a future (post-4.9.3) version will probably answer
with a NOERROR/referral if a query arrives without RD for a name with
non-authoritative matching RR's.  as of 4.9 we are already deleting
all previous data in a node when more-authoritative info comes in.

credibility levels are, in increasing order:

        additional or authority data
        nonauthoritative answer
        authoritative answer
        authoritative local zone (pri or sec)

more details wouldn't be relevant to this thread.  i just wanted to keep
everybody from believing the BIND is still as brain-dead as it used to be.
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<[email-masked]>

--------

--
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, 27 May 2004 04:01:13 +0000

> From: Edward Lewis <[email-masked]>
> ...
> In the past I have tried to add a security options record to a zone, this
> proposal came out in summer 1999, just before the IETF in Oslo (to help fix
> the era in the memory of folks).  One of the pitfalls of this is that the
> record becomes one more issue for inclusion in the non-answer section of a
> reply.  I am off-line now so I can't find the dns-security archives, but I
> recall a message from John Gilmore rejecting the proposal "with prejudice"
> for another reason.  (I recall because I had to ask him what that meant.)

see attached.

Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo
From: John Gilmore <[email-masked]>
To: Paul A Vixie <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 28 Jun 1999 01:49:48 -0700

> > 11. SECure-RR			(5 minutes)		Edward Lewis
> > 	<draft-ietf-dnsind-sec-rr-00.txt>
> i very much hope that john gilmore will be at the oslo meeting to defend his
> point of view (that we can't deploy a new RR at this time if we're expecting
> to use dnssec widely this year.)

I won't be in Oslo, unfortunately.  Hugh Daniel will be there, but
he doesn't have the history.

Deploying an RR type that only exists in superzones is not quite as
bad as deploying one that exists everywhere.  The number of superzones
is smaller than the number of zones, and the most critical superzones
(. and .com and etc) are running on machines that "nominally" always
upgrade to the latest BIND anyway, so they'll be able to serve new RR
types.

Having scanned the draft once:

Summary: REJECT WITH PREJUDICE.  Poorly defined, unnecessarily complex,
doesn't solve the problem it claims to, doesn't even address the
real problems of DNSSEC.

The biggest problem with DNSSEC appears to be paper designs that do
not benefit from operational evolution.  In other words, DNSSEC is not
going through the winning part of the IETF process (draft, implement,
try, redraft, implement, try, ... standardize).  Instead we go through
a series of paper specs trying to standardize them with no operational
experience.  Note I said operational, not programming.

I suggest that we operate with the specs we have and learn from 'em.
THEN change 'em.

This paper design continues many of the problems of prior DNSSEC
drafts; it lays out grand schemes without considering the operational
details.  The open-ended "Security parameters of a zone" is one
example (including things like "Signature policy.  This is an untested
issue.").

The draft goes to even more ridiculous lengths than NXT to secure
negative answers.  (NXT more than doubles the size of your zone, to
give definitive "NO"s for names that aren't in the zone.)  In addition
to NXT, we now have a bitmap in the parent zone (!!!) that gives five
options on how the child zone might handle negative answers.  These
options can be used in combination.  (At least if the WG thinks this
level of abomination is needed, it should be expressed in the child
zone rather than in the parent.  Such a record in the child would be
signed by the zone key, so it can't be spoofed.  Though I suppose its
*absence* could be spoofed, hmm...)

Then we get to the meat.  The SEC record doesn't really have fields
that specify security parameters.  Instead it holds little
sub-packets, each of which has to be parsed, each of which specifies
security parameters.  These sub-packets have option specifier bytes,
optional lengths, and data.  The length of most of the options is
defined in the spec, so that when new options are added, all existing
implementations will be unable to parse them.  The draft specifies
various combinations of options that are not permitted together.  I
don't see why we don't just go straight to X.509 and ASN.1 instead --
it's simpler and easier.

The text file format is highly readable, consisting of a series of hex
numbers.  (At least the numbers are in hex; the DNSSEC KEY record has
bit-flags expressed in decimal.)  The parsing of the hex is screwy;
some fields have 0x, some do not, and this difference appears to have
some meaning, though it's not clear what meaning.

The draft claims it's a successor to Zone Key Referral by me and Jerry
Scharf.  Did I really do that?   It doesn't actually include the name of
the Zone Key Referral draft, but elsewhere it says it's "by the same
authors" (as itself, presumably).

	John

---

From: Paul Vixie <[email-masked]>
Date: Sat, 29 May 2004 06:10:33 +0000

> ...
> I'd put my opinions this way - if providing a way forward were easy
> and/or if providing obfuscation was cheap to do, I'd be for it.  But
> from the work I've done, the costs to do either seem to be rather
> high, meaning that there has to be a lot of need to provide them.

i have a similar conclusion, which is that if we want NSEC to be
upgradeable then it's going to take (at least) some period of time to
find out whether it already is, which will take some modelling.  if it's
not already upgradeable, then it'll take some additional period to
decide how to make it so, which should include competing alternatives,
independent modelling/analysis/review, prototyping, and testing.

i'm calling the first period six weeks, since i know how namedroppers
works.  it could be longer, since it's coming up on summer in a lot of
places, and a lot of namedroppers children will be out of school, and
there will be some vacations.

if there is a second period (see above) then NSD 2.0 will become
out-of-date, and BIND 9.3.0 (now in beta testing but maybe in release
candidacy or actual release by that time) will become out-of-date, and
then the second period is probably around four months, maybe longer
since it will overlap with end-of-year holidays.

since we know that we can push out replacement dnssec technology by
using different type codes for it and changing the time scale from
months to years, it is my hope that on june 1 when WGLC ends, the
chairs will recognize that the dnssec-bis docset appears to meet its
design goals and appears to have adequate document quality and adequate
protocol quality, and forward the documents to IESG for publication.

and then, depending on funding and other resources, this WG can start
work on a DNSSECv2 that uses different type codes to operate "like ships
in the night" with DNSSECv1 and can take a year or even longer to ensure
that its design matches the community's then-current requirements and
that it is implemented straightforwardly and that deployment considerations
are known and handled from day 1.  it can even share/reuse keys, and could
have a gateway back to DNSSECv1.  but it would not be "DNSSECv1 with
versions", since the time between now and when we'll know whether that's
possible is longer than many of us want to wait.  and because DNSSECv1
appears to have achieved its design goals, which did not include 
confidentiality.