Subject: Re: planned obsolescence, and another TCR

From: Greg Hudson <[email-masked]>
Date: Sat, 29 May 2004 20:50:15 -0400

On Sat, 2004-05-29 at 02:10, Paul Vixie wrote:
> i have a similar conclusion, which is that if we want NSEC to be
> upgradeable then it's going to take (at least) some period of time to
> find out whether it already is, which will take some modelling.

It seems like, at the very least, it should be possible to rev all the
DNSSEC record types, such that zones signed with DNSSECtre (which
somehow magically solves the enumeration "problem" with compromising
something equally important) appear unsigned to DNSSECbis-only
resolvers.

This plan might present an upgrade impediment to zones signed with
DNSSECbis; they might have to choose between providing twice as much
data or appearing unsigned to DNSSECbis-only resolvers.  But if the only
reason to upgrade to DNSSECtre is enumeration, then that choice has to
be made anyway (either you didn't deploy DNSSECbis, or you did deploy it
in spite of the enumeration concern, and you won't solve the enumeration
concern without leaving behind DNSSECbis-only resolvers).

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

---

From: [email-masked]
Date: Mon, 31 May 2004 12:38:46 +0200 (CEST)

On Sat, 29 May 2004, Paul Vixie wrote:

> > I'd put my opinions this way - if providing a way forward were easy
> > and/or if providing obfuscation was cheap to do, I'd be for it.  But
> > from the work I've done, the costs to do either seem to be rather
> > high, meaning that there has to be a lot of need to provide them.
>
> find out whether it already is, which will take some modelling.  if it's
> not already upgradeable, then it'll take some additional period to
> decide how to make it so, which should include competing alternatives,
> independent modelling/analysis/review, prototyping, and testing.

There are many possibilities to start an upgrade path, versioning and
such. The REAL problem is specifying resolver behaviour when it encounters
an unknown vesion of NSEC. It will introduce numerous cornercases since
NSEC is used in both negative and positive proofs (this is not FUD, there
were some cornercases in the past when we're trying to model opt-in). It
also needs to be tested very well. CAIDA has recently done some modelling
http://www.caida.org/outreach/papers/2004/dnspam/ and one of the
conclusions is that resolvers tend to become aggressive when denied
certain data. Ignoring incompatible NSEC versions is exactly what that is.

Being one of the authors of the docset and knowing how much effort it took
to get here from where we were 4 to 5 years ago, it will be another year
_atleast_ before something as little as an MBZ will make it through. Going
over the docset again, there are many hooks that needs eyes and text in
case the wg decides on versioning. I'm not saying we shouldn't, but before
we get to where we are now with rough consensus and running code,it will
be another two years.

To my frustration, I think we've REALLY missed the bus on NSEC, since
everything from label types to packetsize, from header bits to transaction
signatures _is_ extendable, while a few of the big namedroppers mud-fights
were due to lack of NSEC versioning.

Having said that, my conclusion is to ship the docset now and get some
real experience in userland. A TCR++ degauss of DNSKEY/NSEC in the near
future can introduce a version scheme for NSEC. That would probably also
take some time, and is bw compatible with DNSSECbis, but at least we can
move forward now.

Roy