Re: DNSSEC - Intermediate Validation - Good or bad idea?

> DNSSEC PNE with intermediate validation has the principle that a 
> single administrative error (e.g. signing the root dnskey rrset with 
> an unknown trust anchor, fat fingering the DS summary of a delegation 
> point) can cause an entire part of the DNS tree to disappear from 
> non-validating end-application view.  This scares me... a lot.

	There are lots of ways whole branches can disappear in the
	DNS today.  DNSSEC just adds a few more.

	I have on a number of occasions said that registries today
	should at delegation time and periodically there after check
	delegations and get the broken ones fixed.  e.g. ensure
	that NS RRsets match, ensure that glue address records
	match, etc.

	I keep getting told "this is not the registry's job" or "we
	can't to this as we have registrars" or "we can't do this
	at delegation time because we have to perform the delegation
	within X seconds", etc.

	The DNSSEC errors above fall into the same class of error.
	I just need someone to decide to take responability for
	what they are doing and *manage* what is happening and not
	race for the almighty buck.

	Mark

	P.S.  I also think that failure to fix delegations in a
	timely maner should result in the delegation being pulled.

Re: DNSSEC - Intermediate Validation - Good or bad idea?

Intermediate validation is a really bad idea.  It's just better than
not doing validation at all.

There's this little problem of the installed base of DNSSEC-oblivious
stub resolvers.  Intermediate validation is the only way I can see to
protect them.  I'd strongly prefer that all stub resolvers eventually
turn into validating stub resolvers, but that'll take a while.

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

DNSEXT list policy

- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.

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

* 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 <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

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,

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 <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, 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 <at> 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 <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: < http://ops.ietf.org/lists/namedroppers/>

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

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

i think the lack of attraction is explainable separately from the quality or
complexity of the current official design.  kc said it best, on one of steve
crocker's concalls, when steve asked "what's the one thing the community
needs to begin dnssec deployment?" and kc answered, "motivation."  dnssec is
a classic internet design, demanded by military/government types.  it is not
like the web or ssl, demanded by the market and/or useful for commerce.  if
you're trying to create motivation, then adding an 8th 11th-hour retrenching
isn't the way.  if you're trying to overcome inertia and/or improve the
cost:benefit toward a more compelling level, then again, adding an 8th 11th
hour retrenching to the schedule is not your best move.

> WRT to Ohta's design - I've actually never seen it.  

that's a sad statement in and of itself.  you're acting like a latecomer who
has all the answers but hasn't done a lot of research and/or homework.  since
i know you better than that, i am mystified.  what kind of deployment community
backing have you received that made your current proposal seem useful?

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

as most of us have been saying for a decade, the major reason to deploy dnssec
is that it will protect nameservers from following evil NS/A/AAAA chains.  if
there's a secondary benefit (that dnssec is useful in commerce or antispam
or antiphish or whatever) then such secondary benefits will not be known or
visible until after the basic infrastructure is in place.  that's due to the
chicken-or-egg problem, folks won't sign their zones until it improves their
lives, and folks won't install a validators until it improves their lives.
something had to be the first mover.  obviously, that's the NS/A/AAAA chains.

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

here, you are preaching to the choir.  i wasn't going to propose EDNS until
DNSSEC was done, but in 1998 donald eastlake convinced me that there was time.
michael graff and i decided not to propose "slabbed DNS" with security as
metadata in 2002 because we didn't want to muddy the waters.  a bazillion
people have told me not to bother deploy DLV since NSEC3 is coming real soon
now.  a couple of times per year, i drag something up from the old jim galvin
dns-security mailing list archive and repost it to namedroppers under the
subject, "on this date in 1997" or whatever, and it'll be the same thread all
over again.  i hate this whole thing.  dnssec is the worst design-by-committee
effort i've ever seen, both in terms of how late it is, how fuzzy the goals
have been, how often the goals have changed, and how complicated and heavy it
is now that it is trying to be all-things-to-all-people.

but you won't improve it by adding an 8th 11th-hour redesign.  all you could
do would be to convince anybody who has been waiting for dnssec that they'll
have to go their own way.  are you failing to grasp that any change to the
way this stuff works will take at least two years to stop arguing about and
test-in-lab and write code for and so on?  and that the real deployment work
will not begin until those moments stop coming?  and that real deployment
will take five years once it starts?

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

never.  because the IETF is a vastly different organization than it used to
be.  and while you're hitting on the reasons we tried to start MODA, that's a
separate discussion (and, MODA is dead, since it could not overcome inertia.)

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

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

At 0:18 +0000 12/3/06, Paul Vixie wrote:

>
(MSJ) > WRT to Ohta's design - I've actually never seen it.
>
>that's a sad statement in and of itself.  you're acting like a latecomer who
>has all the answers but hasn't done a lot of research and/or homework.  since
>i know you better than that, i am mystified.  what kind of 
>deployment community
>backing have you received that made your current proposal seem useful?

That's a bit harsh.  Ohta's proposal is very hard to find.  I've 
tried, and eventually did get a copy.   Here's a URL for it.

http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt
--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

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

Back to Ohta's old proposal (Was: DNSSEC - Signature Only vs the MX/A issue.

On Sat, Dec 02, 2006 at 10:26:15PM +0000,
 Paul Vixie <paul <at> vix.com> wrote 
 a message of 65 lines which said:

> 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

Thanks to the archaeologist Ed Lewis, I've read this draft and I'm
puzzled: it does cover PNE for domains, with the ZL record (and PNE
for types with the RRD record). Ohta's proposal does not seem to be SO
and therefore does not seem to be a direct competitor of St John's.

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

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

On Sat, Dec 02, 2006 at 09:14:18PM +0100,
 Florian Weimer <fw <at> deneb.enyo.de> wrote 
 a message of 19 lines which said:

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

This moves the complexity to the resolver, which would have to
remember, when receving (NOERROR, Answer=0) to retrieve the signed
bitmap and to check it.

But, yes, it seems simpler than the RRD in Ohta's draft (recently
resurrected).

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