Subject: Re: DNSEXT WGLC: DNSSEC Opt-in

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Feb 2003 21:35:23 +0000

> One of the concerns that I have heard is that DS without Opt-In really
> needed those workshops in order to expose some corner cases and that
> Opt-In really has not had the kind of workshop trials that DS has had.

yes, i saw that same kind of ballotbox stuffing going on, too.

> Have I missed those workshop announcements, and, if so, are there public
> results I could catch up on?

fun was had in amsterdam, the week before ripe, and opt-in saw some testing.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 21:22:17 +0000

> I oppose OPT-IN going forward as a proposed standard.  
> 
> It is very clear that there are some engineering trade-offs here, ...

that's not as clear to me as it seems to be to you.  opt-in adds another
knob for zone managers, some of whom will twist it for engineering reasons
(such as difficulty in signing and publishing large zones with current
technology) but some of whom will twist it for non-engineering reasons
(such as a desire to limit the public exposure of complete NXT chains,
either for business or privacy reasons.)

> Based on that, I believe we would be making the wrong choice to
> advance OPT-IN; if we allow it, it will be part of the standard for a
> very long time, and we will be living with its complexity well past
> the time horizon that the problems it addresses have ceased to be an
> issue.

because there are reasons for the knob which existing zone managers
consider valid, some of which are engineering related and of those some
appear to be temporary, but others of which are not engineering related,
i believe that the tradeoff is between complexity and autonomy, and that
autonomy has to win since the complexity has already been shown to be
quite manageable (witness various recent workshops and bind9 snapshots.)

it is not up to us as protocol developers to tell zone managers how they
ought to "run their businesses."  that would be paternalism at its offensive
worst, worse even than the "restrict key" silliness.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2003 03:00:35 +0000

> This point of view, that the OPT-IN mechanism is there primarily to
> provide a knob for zone managers to use in running their businesses,

i don't think i said "primarily".  here, let's look:

> > it is not up to us as protocol developers to tell zone managers how
> > they ought to "run their businesses."  that would be paternalism at
> > its offensive worst, worse even than the "restrict key" silliness.

it's an aspect of what ought not be done, that's all.

> does not seem to me well laid out in the draft.  If the justification
> is based on this, then I would say making clear which new knobs are
> needed to do what would be a very useful thing.

the justification is not based on this.  however, some zone managers
have said that they want this and have put the onus on the standards
community to say why they can't have it.  i don't think there's a
reasonable basis for denying the request for this feature.  dnssec is
such a step upward in complexity and brittleness from basic dns, that
the incremental complexity from opt-in is pretty much lost in the noise.

> This is not "paternalism", but a way of making clear to everyone what
> the benefit of a change is going to be.  It's important for all of us
> to remember that zone managers are not the only ones concerned in the
> operation of the DNS; those who run recursive resolvers and manage
> applications relying on data stored in the DNS are concerned as well.
> This mechanism has implications for them, and considering those
> implications in the protocol design is appropriate.

i believe i have, since opt-in vs. not has been shown to be an early
deployment issue, and early deployment is going to affect the quality
of the "protocol experience" by recursive server operators and application
managers more than either elegance or any real or imagined incremental
difference in complexity.  it is in other words far more likely that a
given application manager or recursive server operator will avoid dnssec
altogether than that they will face any noticable complexity penalty due
to opt-in.