Subject: Re: Transition from 2535 to opt-in

From: [email-masked] (Ted Lindgreen)
Date: Sat, 8 Dec 2001 12:03:16 +0100

[Quoting Paul A Vixie, on Dec  8,  2:47, in "Re: Transition from  ..."]

> does anybody other than me think that if we're still addressing issues at
> this fundamental level five+ years into the project, that we're just doomed?

Well, my solid conclusion, after leading a team of DNSSEC developers
for the past years is, unfortunately, that you are right about the
first part of above question.

About the last part of your question... I'm very close to agree.
Well, in fact... let me explain:

At the London meeting (not during an official meeting, but a
side-one, where most of the DNSSEC specialists, some 40 people,
met), the question was raised:
  "Is the DNS cache poisoning threat still an issue here?"

A surprisingly large part, well the overly majority of the
people present, reacted in the range between:
  "Hmm, no, this is mostly fixed already, isn't it?"
and
 "Well, no, at least that's not why we want DNSSEC."

During the official meeting where other security people were
dominating, the wind blew from an other direction.  The need to
recap the threats was adviced, and in the mean time a draft is
presented (draft-ietf-dnsext-dns-threats-00.txt by Atkins and
Austein).

We were totally puzzled with development going one way, and dnsops
talking about another.  As a result, we, NLnet Labs, have put our
DNSSEC development work on ice.  Without a common goal, it is
impossible te determine a direction.

And therefore, I keep asking (and feel like a broken record) the
question: please let's restate our goal again.

Then, I see 3 possible outcomes (but there will, no doubt be more,
and hopefully better):
1. The goal remains: "Protect the DNS infrastructure"
   Then, we should focus on either deployment on 2535, with only
   the real necessary modifications, or conclude that 2535 won't 
   ver work, and put our focus on developing DNS-2 or some
   other alternative.
2. If the goal is: "A cheap PKI".
   Then, let's design, build and implement a cheap PKI, and please
   don't try to clobber into DNS.
3. A compromise, where only "the info the must be signed, is signed".
   Then, the right way is to strip RFC 2535 to do just that, and
   not increase its complexity with opt-whatever.

Anyway, when above decision is made, NLnet Labs is ready to join
the development-party again, but as longs we are directionless,
we will standby.

Regards,
-- ted

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 08 Dec 2001 08:17:36 -0800

>   "Hmm, no, this is mostly fixed already, isn't it?"

they were wrong.  it's not fixed.  it's not fixable without a protocol change.

>   "Well, no, at least that's not why we want DNSSEC."

had i been there i would have said "this is only one of several reasons why i
want dnssec."  folks use "cheap PKI" as a covering term but it's a misnomer.
there's a whole class of data which i won't use the DNS to propagate because
DNS is extremely spoofable.

> Anyway, when above decision is made, NLnet Labs is ready to join the
> development-party again, but as longs we are directionless, we will
> standby.

isc, on the other hand, remains only as committed as the people who fund us.

right now the thing i see as needing work is the protocol development process
itself.  irrespective of the comments from verisign labs here yesterday, i get
the impression that dnssec won't be allowed to progress to the point where it
is "stable enough" for deployment until several namedroppers decide to retire.
(the verisign counter-challenge was that dnssec can't be stable until it's
feature-complete.  that skins the same cat but indirectly.)