Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO)
Paul Vixie <paul@vix.com> Thu, 27 May 2004 04:01 UTC
From: Paul Vixie <paul@vix.com>
Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO)
Date: Thu, 27 May 2004 04:01:13 +0000
Lines: 116
Sender: owner-namedroppers@ops.ietf.org
References: <edlewis@arin.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-From: owner-namedroppers@ops.ietf.org Thu May 27 06:12:23 2004
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Wed, 26 May 2004 22:48:10 -0400." <a06020401bcdac129a91d@[192.35.166.53]>
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk
X-Message-ID:
Message-ID: <20140418071837.2560.39199.ARCHIVE@ietfa.amsl.com>
> From: Edward Lewis <edlewis@arin.net> > ... > 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 ---
- the KEY debate Michael Richardson
- Re: the KEY debate Rob Austein
- Re: the KEY debate Simon Josefsson
- Re: the KEY debate Rob Austein
- Re: the KEY debate Mark.Andrews
- Re: the KEY debate Dan Massey
- Re: the KEY debate Ted Lemon
- Re: [Design] Re: the KEY debate Mark.Andrews
- Re: [Design] Re: the KEY debate Rob Austein
- Re: the KEY debate Ólafur Guðmundsson
- Re: the KEY debate Jakob Schlyter
- Re: the KEY debate Edward Lewis
- Re: the KEY debate Paul Vixie
- Re: [Design] Re: the KEY debate Rob Austein
- Re: [Design] Re: the KEY debate Dan Massey
- Re: the KEY debate Edward Lewis
- Re: the KEY debate Paul Vixie
- Re: the KEY debate Jakob Schlyter
- Re: [Design] Re: the KEY debate Michael Richardson
- Re: [Design] Re: the KEY debate Michael Richardson
- Re: [Design] Re: the KEY debate Scott Rose
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: the KEY debate Robert Elz
- Re: the KEY debate Derek Atkins
- Re: the KEY debate Edward Lewis
- Re: the KEY debate Robert Elz
- Re: the KEY debate Paul Vixie
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate bert hubert
- Re: [Design] Re: the KEY debate Simon Josefsson
- Re: [Design] Re: the KEY debate Simon Josefsson
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Jakob Schlyter
- Re: [Design] Re: the KEY debate Ólafur Guðmundsson
- Re: [Design] Re: the KEY debate Michael Richardson
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Scott Rose
- RE: [Design] Re: the KEY debate Hallam-Baker, Phillip
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate David Conrad
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Jakob Schlyter
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Derek Atkins
- RE: [Design] Re: the KEY debate Jason Coombs
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Ted Lemon
- Re: [Design] Re: the KEY debate Edward Lewis
- RE: [Design] Re: the KEY debate Jason Coombs
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Ted Lemon
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate John Schnizlein
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate David Conrad
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate Derek Atkins
- Re: [Design] Re: the KEY debate David Blacka
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Simon Josefsson
- Re: the KEY debate Rob Austein
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Brian Wellington
- Re: [Design] Re: the KEY debate Eric A. Hall
- Re: [Design] Re: the KEY debate Mark.Andrews
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Edward Lewis
- RE: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Edward Lewis
- Re: [Design] Re: the KEY debate Scott Rose
- RE: [Design] Re: the KEY debate Hallam-Baker, Phillip
- Re: [Design] Re: the KEY debate Ted Lemon
- RE: [Design] Re: the KEY debate Hallam-Baker, Phillip
- Re: [Design] Re: the KEY debate Mark.Andrews
- Re: DNSSEXT Yokohama Minutes Paul Vixie
- Re: Wildcard elimination (Was Re: DNSEXT Yokohama… Paul Vixie
- Re: dynamic update zone Bill Sommerfeld
- Re: DNSSEXT Yokohama Minutes Paul Vixie
- Re: DNSSEXT Yokohama Minutes Paul Vixie
- Re: opt-in and large zones Paul Vixie
- Re: inconsistency between rfc 2136 and rfc 2845 Paul Vixie
- Re: on-offline keys : was RE: Delegation Signer R… Paul Vixie
- Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.t… Olaf Kolkman
- Re: DNSEXT WGLC: DNSSEC Opt-in Paul Vixie
- Re: comments on ds-13 Paul Vixie
- Re: comments on ds-13 Michael Richardson
- Re: comments on ds-13 Randy Bush
- Re: comments on ds-13 Rob Austein
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Paul Vixie
- Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Paul Vixie
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Roy Arends
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Matt Larson
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Olaf Kolkman
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Mark Kosters
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Scott Rose
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Ted Hardie
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Randy Bush
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Ted Lemon
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Mark Kosters
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Randy Bush
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Mark Kosters
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Bob Halley
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN David Conrad
- Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Frederico A C Neves
- Re: concerned - RE: TXT records, are they alive? Paul Vixie
- Re: Q-03: inclusion of KEY records in additional … Paul Vixie
- Re: Q-03: inclusion of KEY records in additional … Paul Vixie
- Re: proposed definition for the NXT Paul Vixie
- Re: comments on ds-13 Paul Vixie
- Re: Q-10: Reaction to "Silly" NXT's Paul Vixie
- Re: NXT processing at resolvers, the anomalies... Paul Vixie
- Re: NXT processing at resolvers, the anomalies... Paul Vixie
- Re: question regarding wildcards and 2672 Jim Reid
- Re: question regarding wildcards and 2672 Paul Vixie
- Re: wild cards and NS records Paul Vixie
- Re: On wild cards Paul Vixie
- Re: wcard-clarify scope confusion Paul Vixie
- Re: LLMNR interoperability with Rendezvous? Paul Vixie
- Re: wildcard as empty non terminal Paul Vixie
- Re: LLMNR authorized range Paul Vixie
- Re: LLMNR authorized range Paul Vixie
- Re: handling of additional data (fwd) Paul Vixie
- Re: NSEC2- and an Authenticated Denial Mechanism … Paul Vixie
- planned obsolescence, and another TCR Paul Vixie
- Re: NSEC version field (Re: NSEC2- and an Authent… Paul Vixie
- Re: zone-covering NSEC ranges -- "which is it?" Paul Vixie
- Re: TCR Paul Vixie
- Re: NXT design choices Paul Vixie
- Re: was Re: Avoiding collisions Paul Vixie
- Re: wild cards Paul Vixie
- Re: another's view on zone enum & on-line signing Paul Vixie
- draft-ietf-dnsext-signed-nonexistence-requirement… Loomis, Rip
- Re: another's view on zone enum & on-line signing Jim Reid
- Re: another's view on zone enum & on-line signing Paul Vixie
- Re: private algorithms and the DS record Paul Vixie
- Re: Who hates the DNAME? Paul Vixie