Subject: chairs' message on opt-in

From: Randy Bush <[email-masked]>
Date: Sun, 4 May 2003 18:34:08 -0700

the wg last call on [ds-only] opt-in is over.  it's a tough issue
and the wg discussion has been muddy, to be kind.

1 - there seems to be consensus that the spec is complete and
    correct.  this was determined in a separate last call.

2 - is there consensus that opt-in adds complexity?  probably yes,
    but folk disagree on how much and disagree on the impact of
    that complexity on dns operation and on security.

3 - is there consensus that opt-in changes the security model from
    'simple dnssec'?  yes.  is that change bad?  opinions differ.

4 - is there consensus that deployment of dnssec is important?
    yes.

5 - is there consensus that opt-in may help deployment of dnssec?
    yes, for a few very large zones.

6 - it might not be obvious how to come to a decision here - or
    even whether we can come to a decision.

    the question asked of the WG was:

    "is there consensus in the wg, to allow ds-only opt-in in
    zones?"

    the way this is phrased the default action, which is what
    applies should there not be rough consensus, is to not add the
    opt-in feature to the protocol.

    one might argue that the question was asked in a biased manner
    and the question should instead have been asked as:

    "should we allow or not allow opt-in zones?"

    first, it is traditional and reasonable to place the onus of
    consensus on *additions* to protocols, since it is likely to
    lead to less features in protocols if each added feature needs
    wg rough consensus.  i.e., this was normal wg procedure.

    second, and possibly more important, had the question been
    asked that way, we would have the equivalent of a hung jury
    with no process for how to move forward at all.

7 - is there consensus that consensus-5 should override consensus-2
    and consensus-3?  discussion varied, folk had opinions on both
    sides.  underneath the flamage, there was actual disagreement,
    with knowledgeable parties on both sides of the fence.  this is
    not consensus.

given that we all want to move forward the chairs, given the
process, have no choice but to come to the following conclusion:

    there is no consensus to add opt-in.

randy & olafur

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 4 May 2003 19:23:36 -0700

It seems somewhat strange to place the burden of proof on
changes to a protocol that has been undeployable for ten
years.

The bias in favor of the status quo is understandable in the
case of a protocol that is deployed. A bias in favor of inaction
when a protocol has been undeployed for a decade is a farce.

A bias in favor of inaction when the chairs choose to put the 
question repeatedly until they receive the answer they want
is a farce.

The chairs and the group will therefore understand why 
discussion of this matter must now move to other forums,
starting with the IESG.

		Phill

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Sunday, May 04, 2003 9:34 PM
> To: namedroppers
> Subject: chairs' message on opt-in
> 
>

---

From: [email-masked] (Ted Lindgreen)
Date: Mon, 5 May 2003 11:01:33 +0200

[Quoting "Hallam-Baker, Phillip", on May  5,  4:34, in "RE: chairs' message  ..."]

> changes to a protocol that has been undeployable for ten

I have a problem with this statement in the context of the opt-in
discussion: it seems to imply that it is impossible to deploy DNSSEC
in its current state, but that it can be deployed when opt-in is
added.

If this is what Phillip indeed intends to say, then I would like
to remind him of the following:

1. It took until 1999/2000 before an implementation was ready
   for test, in fact, two implementations became available short
   after each other: BIND8.2.2p5 and BIND9. That is three years
   ago, not ten years.
2. Immediately after these implementations became available, a
   number of organisations, among which was NLnet Labs in
   collaboration with CENTR (European ccTLDs), started deploying
   DNSSEC in various scale test situations. TLD zones were
   signed, loaded, and queried in test-nameservers to check the
   deployability.
3. In contrast to what many feared, it turned out that there was
   NO problem in signing and running even the largest zones,
   like .de and .com. For .de and .com one needs a system with
   a 64-bit architecture, but 64-bit systems are available and
   affordable nowadays.
4. However, these early experiments did reviel, that having the
   child's KEY present and signed in the parent's zone would lead
   to a very big organizational problem for TLDs. (The most optimized
   scheme we could devise to perform a scheduled key roll-over needed
   11 steps between Registry and Registrant, while we could not
   devise a workable scheme to perform an emergency key roll-over).
   Thanks to other WG-members, the DS RR was developed as a solution.
5. Since DS is available, there are a number of TLDs (at least .nl,
   .se, and .fr, but probably more) that deploy DNSSEC in a test-
   environment. These tests run stable.

There has been some discussion on the size of a signed non-optin .com
zonefile, but both theoretical analysis and real experiments have
shown that deployment of RFC2535+DS is quite possible in .com, with
or without the opt-in addition.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 5 May 2003 08:18:20 -0700

>    after each other: BIND8.2.2p5 and BIND9. That is three years

I said that the protocol has been undeployable for ten years.

If Ted can tell me how the protocol could have been deployed 
without code I am interested to hear it.

As Ted points out the trial deployments uncovered a large number
of problems, including the large zone issue. If one of the chairs 
had not chosen to behave in the way he did the large zone issue
would also have been addressed by the group.

As it is the chairs have decided that this group did not decide.
Therefore the proposal moves onto another forum.

	Phill

---

From: [email-masked] (Ted Lindgreen)
Date: Mon, 5 May 2003 18:43:02 +0200

[Quoting "Hallam-Baker, Phillip", on May  5, 17:39, in "RE: chairs' message  ..."]
> without code I am interested to hear it.

It could not, that was my statement: trail deployments take place
for three years now, much too long, but not ten years.

> .......

1. I certainly never pointed out anything like that.
   On the contrairy: the trial deployments uncovered surprisingly
   few problems. Especially they uncovered that the much feared
   "large zone" problem, was a non-issue: we showed that even with
   an entry-level desktop computer, a Compaq DS-10, we could sign
   and run the .de and .com zonefiles. Of course the .com zone was
   smaller at that time, but computer-power has grown an order of
   magnitude more than the .com zone has grown since.

   Phillip must have missed large parts of the DNSSEC development
   since 2000, so I'll repeat:
     The one and only serious deployment problem we uncovered was
     the maintenance of the registrants KEY in the registry's
     zonefile. This problem has been fixed by the DS RR.
     As a side-effect, with the DS RR we also got rid of the null-key,
     and this further reduced the already manageable "large zone"
     issue by a factor of two for  large zones with few secured
     delegations.

2. Please stop this childish "chair bashing" game.

-- ted

---

From: Roy Arends <[email-masked]>
Date: Mon, 5 May 2003 19:08:57 +0200 (CEST)

On Mon, 5 May 2003, Ted Lindgreen wrote:

> the trial deployments uncovered surprisingly few problems. Especially
> they uncovered that the much feared "large zone" problem, was a
> non-issue: we showed that even with an entry-level desktop computer, a
> Compaq DS-10, we could sign and run the .de and .com zonefiles. Of
> course the .com zone was smaller at that time, but computer-power has
> grown an order of magnitude more than the .com zone has grown since.

Sure, with a reliable, secure and homogeneous network, zero latency,
infinite bandwith, stable topology, zero transport cost and a single
administrator [1], I can imagine it is quite possible, today, but only
today, with 64 bit, no crypto-certified hardware, meanwhile hoping that
IPv6, IDN and ENUM never takes off, since the .com zone might grow, and
the argument will not hold sway.

It took 3 years before moore's law projected on todays hw with 3 yr old
stats would become valid.

Applying Moore's law is valid when applied to all variables, including
data size, not just the ones that fits the argument.

Today's DNSSEC just doesn't scale.

Roy

[1] The Eight Fallacies of Distributed Computing.
    http://java.sun.com/people/jag/fallacies.html

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 May 2003 19:28:06 +0200 (CEST)

> Yes, this is an opt-in opponent saying "any clients that ship today
> need to have opt-in support".  Given that the process hasn't
> concluded, I think that's the only safe way to move forward.

Sam, 

I'm trying to understand your suggestion.
At what point in time do you think we can declare that the process has
concluded?

AFAIK there isn't a time limit for when an appeal can be filed,
and there isn't anything that prevents a WG from changing a previous decision
any time it wants to.

   Erik