Hi Paul -
Thanks for your note, and I appreciate it's not an attack on me.
You asked why:
Sunk Cost -- A cost incurred in the past that will not be affected
by any present or future decision. Sunk costs should be ignored in
determining whether a new investment is worthwhile.
The above, although cribbed from a government publication is a good
general business practice - ignoring it is how businesses go
i for one think that would
be a bad idea, both because we
have invested a lot of time and money in the current
Unfortunately, that sentiment seems to be widespread.
The entire development of DNSSEC up to this point is sunk costs - the
amount of investment is no predictor of the success of the
development. After 14 years, with no firm date for completion in
sight and no guarantee that there won't be yet another show stopper - I
think it's reasonable to re-consider the direction, or at least have some
fall back position.
Here's the timeline as I understand it:
~1986 - the Protocol Standards technical panel of the DOD identified the
need to have a way to validate DNS data
~1992-3 - TIS submitted a proposal to ARPA for research in this area - a
3+ year contract (or maybe a task order against an existing contract) was
1999 - DNSSEC was declared done with the publication of RFC2535
2000-2002 - OK, maybe some twiddles - new RFCs covering some changes - no
real deployment of DNSSEC
2003 - Publication of DS RFC
2004 - Typecode rollover discussions
2005 - DNSSEC declared done again with the publication of 4033, 4034,
2005 - OK... maybe not done - NSEC not sufficient for certain zone
operators - some zones (e.g. NL) signed, few signed
2006 - Still working on NSEC3, few signed delegations
2007 - Maybe NSEC3 complete, maybe more show stoppers
So blaming my proposal as a distraction seems to be a bit ...
unreasonable. It may be more reasonable to blame the lack of
attraction of DNSSEC to the zone operators and the lack of any
application driven desire for DNSSEC for its failure to take hold up to
WRT to Ohta's design - I've actually never seen it. It may be
perfectly fine, but my guess is that it doesn't provide even a hint of
interoperability with the 4033-4035 DNSSEC and I was hoping to at least
use the existing server code base.
In general, my proposal is targeted at the space mostly ignored by PNE
DNSSEC - that of how an application uses signed DNS data. I don't
actually consider this a change in direction, rather one that could focus
this deployment on the use of the data rather than simply the signing of
it for signing's sake.
I've heard the sentiment "Stay the course" too much over the
last 4 years -both here and in American politics - the arguments for both
tend to get weaker the longer things go on.
Finally, you asked about 11th hour. When I came back into this 4
years ago people swore it was done and that other proposals weren't
needed. Last year it was "NSEC3 is almost done - have
patience" - the same this year. I actually waited three and a half
years on this or 25% of the total time period. While it may be true
that NSEC3 is almost, I can't predict the future and sunk cost analysis
suggest that I shouldn't attempt to. So the proposal came out after
many patient years. I'm sure if I had submitted this at the
beginning of the NSEC3 discussions I would have gotten the same
"11th hour" comments. So feel free to ignore it - I''ll
keep it live as a draft for a year or so and we can talk about 11th hour
issues again in about a year or two while we're waiting for NSEC4.
You decry my timing and strategy, but I ask you when if not now?
Should I have submitted this as a place holder 3 years ago when roughly
the same argument was made to me? Should I have waited until NSEC3
was complete - if ever? Never? If the latter really is the
answer, then the IETF is a vastly different organization that it used to
At 05:26 PM 12/2/2006, Paul Vixie wrote:
i'm having trouble understanding
the scope of this discussion. the working
group refused to consider a simpler design that lacked, among other
secure nxdomain. masataka ohta wrote up a viable proposal 11 years
the working group went the other direction. now, to the extent that
will ever be deployed, the industry as represented in this working group
chosen to deploy a more complicated design.
if we are readdressing our original scope, then let's look at masataka
simpler design from 11 years ago, and let's stop working on NSEC3 and
lies" and so on. i for one think that would be a bad idea,
both because we
have invested a lot of time and money in the current design, and because
more comfortable with secure denial of existence, even with all its
but this third way forward is mystifying me. i am mystified that
it up at all; i am curious to know who, among the deployment communities
are domain holders, domain registrars, domain registries, client
server implementors, server operators, and internet governance
feels ready to discard the current design at this, the 11th hour (which
have already reached and retreated from seven times in 12 years), and
back to something that the industry rejected in 1995 or so when
kaufman was chosen over the ohta design. and if we're moving
are we reinventing it rather than reusing ohta's perfectly reasonable
i am completely amazed to see anyone here arguing technical merits on
fundamental change in direction. does anyone really believe that if
starts over an 8th time on this technology, that any potential deployer
ever again take this working group seriously?
msj, this isn't a personal slam. from a quick glance, your proposal
be every bit as good as ohta's. the quality of the proposal is not
only the timing and strategy.
> From: Florian Weimer <fw <at> deneb.enyo.de>
> To: Mike StJohns <Mike.StJohns <at> nominum.com>
> Cc: namedroppers <at> ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
> Date: Sat, 02 Dec 2006 21:14:18 +0100
> Sender: owner-namedroppers <at> ops.ietf.org
> * Mike StJohns:
> > Any other ideas in this general topic?
> I think this could be addressed in a straightforward manner,
> the spirit of SO, if you published a signed bitmap of all
> RTYPE/RCLASS combinations for a particular value.
> If you wonder if this is worth the additional complexity, it seems
> me that this is less complex than the A/MX heuristics described
> earlier in the thread. At least it's completely
> There is a significant overhead, of course, compared to SO as
> proposed, but less so compared to plain old DNS.
> to unsubscribe send a message to namedroppers-request <at> ops.ietf.org
> the word 'unsubscribe' in a single line as the message text
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org
the word 'unsubscribe' in a single line as the message text body.