Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO)

[Paul Vixie <[e-mail]>]

> From: Edward Lewis <[e-mail]>
> ...
> 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.

--- Begin Message ---

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

--- End Message ---