[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNSSEC - Signature Only vs the MX/A issue.

Hi Paul -

Thanks for your note, and I appreciate it's not an attack on me.  You asked why:

From http://www.whitehouse.gov/omb/circulars/a094/a094.html -


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

 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,

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

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, 4035
2005 - OK... maybe not done - NSEC not sufficient for certain zone operators  - some zones (e.g. NL) signed, few signed deletations
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 this point.

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

Later, Mike



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 things,
secure nxdomain.  masataka ohta wrote up a viable proposal 11 years ago and
the working group went the other direction.  now, to the extent that dnssec
will ever be deployed, the industry as represented in this working group has
chosen to deploy a more complicated design.

if we are readdressing our original scope, then let's look at masataka ohta's
simpler design from 11 years ago, and let's stop working on NSEC3 and "white
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 i am
more comfortable with secure denial of existence, even with all its costs.

but this third way forward is mystifying me.  i am mystified that msj brought
it up at all; i am curious to know who, among the deployment communities (who
are domain holders, domain registrars, domain registries, client implementors,
server implementors, server operators, and internet governance institutions),
feels ready to discard the current design at this, the 11th hour (which we
have already reached and retreated from seven times in 12 years), and move
back to something that the industry rejected in 1995 or so when eastlake/
kaufman was chosen over the ohta design.  and if we're moving backward, why
are we reinventing it rather than reusing ohta's perfectly reasonable design?

i am completely amazed to see anyone here arguing technical merits on another
fundamental change in direction.  does anyone really believe that if the ietf
starts over an 8th time on this technology, that any potential deployer will
ever again take this working group seriously?

msj, this isn't a personal slam.  from a quick glance, your proposal looks to
be every bit as good as ohta's.  the quality of the proposal is not in doubt,
only the timing and strategy.

re:

> From: Florian Weimer <fw@deneb.enyo.de>
> To: Mike StJohns <Mike.StJohns@nominum.com>
> Cc: namedroppers@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@ops.ietf.org
>
> * Mike StJohns:
>
> > Any other ideas in this general topic?
>
> I think this could be addressed in a straightforward manner, keeping
> the spirit of SO, if you published a signed bitmap of all permitted
> RTYPE/RCLASS combinations for a particular value.
>
> If you wonder if this is worth the additional complexity, it seems to
> me that this is less complex than the A/MX heuristics described
> earlier in the thread.  At least it's completely deterministic.
>
> 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@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: < http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: < http://ops.ietf.org/lists/namedroppers/>