Subject: Appeal against decision of DNSEXT working group chairs to prevent progess of OPT-IN

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Apr 2003 12:00:25 -0700

The last call on OPT-IN having expired on March 31st and the chairs
having not responded to the clear consensus of the working group to allow
the drafts to go forward, I hereby appeal against the apparent decision of
the chairs to prevent the progress of the OPT-IN proposal.

	I have counted the statements on the last call issue, only 2 are
opposed outright, while 12 are in favor. 6 state that they are opposed to or
do not like the proposal but are willing to allow it to progress for the
sake of consensus. 1 party failled to make a clear statement on the issue
during the Last Call period but subsequently stated that his statement
should be counted as opposition.

The grounds for the appeal are as follows

1: Technical necessity.
	Deployment of DNSSEC is not practical in the large zones without
modification to address the shortcommings of the original specification. The
original specification is now ten years old and has failed to achieve any
meaningful degree of deployment. It is clear that it will not achieve
meaningful deployment without the active support of the operators of the
large zones.

2: Procedural abuse.
	The chairs have failled to recognise the clear consensus of the
group. They have made repeated requests for last calls in a transparent
attempt to arrive at the answer they favor. New procedures have been
invented to prevent progress of the specification.

3: Failure to observe open process
	The decision process applied in the case of DNS-SEC OPT-IN does not
meet criteria that any independent party or court of law could consider to
be open.

This appeal is made by Phillip Hallam-Baker acting in his individual
capacity and not on behalf of VeriSign or any other party.

In point of fact i have deliberately not forwarded this to anyone else in
VeriSign for comment, in particular to avoid placing Mark and Leslie in an
awkward position.

The right to seek redress in other forums is expressly reserved.

1) Technical Necessity:

	The DNSSEC specification is now ten years old. Despite repeated
warnings of the severe consequences of a compromise of the DNS system to the
fabric of the Internet the IETF has failled to deploy any system to mitigate
or control these risks.

	Revision of the DNSSEC specifications in the DNSEXT working group
has revealled numerous shortcommings in the specifications, most of which
have been accepted as requiring changes, whether major or minor in order to
achieve a deployable specification.

	The one exception to this willingness to accept change has been the
issue of the cost of generating NXT records in the large zones. As matters
stand the deployment of DNSSEC is unduly burdensome to operators of the
large zones as it will cause an immediate six fold increase in the volume of
data in the zones. This fact is not in dispute, only the significance of the
fact and whether the operators of the large zones should simply be required
to accept this cost is in dispute.

	The OPT-IN proposal is a simple piece of engineering that eliminates
most of the excess costs of operating DNSSEC in a large zone where takeup of
DNSSEC is negligible. The working group has completed a last call on the
technical merits of OPT-IN and it has been determined that the specification
is sound technically. This issue is not in dispute.

	The issue of the burdensome costs of deployment and the technical
merits not being in dispute, what then can be in dispute? The issue the
Working Group chairs have chosen to accept as an issue that should block
progress of OPT IN is the question of whether the specification should be
modified to meet the needs of operators of large zones, and by implication
the needs of their ultimate customers, the owners of domain names.

1A) In an Engineering Decision, Commercial Logic MUST suport Technology

	Various stratagems have been applied to prevent the admissibility of
the commercial logic that no operator of a large zone is going to commit
millions to the deployment of a specification if the vast majority of those
costs could be eliminated through a simple modification of the protocol. 

	This argument is further reinforced by the fact that DNSSEC has not
been deployed for over a decade. It is very likely that DNSSEC will never be
deployed on an appreciable scale whether or not OPTIN is accepted. The
responsibility for this fact rests in large part on the chairs of the
working group who have allowed to pass the best chance for deployment of
DNSSEC, the transistion of the .COM and .NET zones to the ATLAS
infrastructure. As was repeatedly made clear to all concerned deployment of
DNSSEC could proceed as a part of the ATLAS rollout provided that the
specification was agreed in time. Deployment of DNSSEC must now be justified
in very different and much harder to achieve terms.

	Yet another factor making commercial deployment of DNSSEC on any
terms difficult is the manifest lack of a necessary Internet application
that cannot be deployed without DNSSEC and the lack of buy-in from the major
platform vendors. When I tell people that I am working on DNSSEC I am most
often asked if that had not died a decade ago, then they ask if I am still
writing code for PDP-11 or if I am ready to make the leap to VAX?

	Given these obstacles to deployment it is clear that the accusations
of OPTIN opponents that the proposal is some sort of plot to kill DNSSEC is
clearly false. DNSSEC is to all intents and purposes dead. OPTIN and the
related improvements are an attempt to re-animate the corpse.

	There is still a chance that DNSSEC can be deployed, in particular
the prevelance of SPAM demonstrates a clear need for a mechanism for
advertising security policy so that an email recipient can verify the sender
address to see if the purported sender does in fact authorize the mode of
delivery. If secure the DNS is one candidate for that advertisement
mechanism. Another initiative the author has been involved in has been the
promotion of XKMS and DNS linked PKI as a means of superceeding the failed
concept of deploying and X.500 directory at Internet scale.

1B) Chance of Divergent Deployments

	In essence the Working Group has told the large registrars that
their concerns are of no importance. This is a dangerous situation since
divergence in the DNS specifications can only be avoided if the large
registrars continue to support a group that has stated that it does not
intend to support them.

	Already there are proposals to deploy OPTIN, either on the basis of
an Experimental RFC or on the basis of no RFC at all. While some of the
consequences of this divergence could be mitigated it is surely better to
prevent it taking place.

	Asking the parties that are being told that their issues do not
count not to make unpleasant threats is not going to prevent a divergence.
All that strategy would achieve is to ensure that when the inevitable
occured it would come as a complete surprise.

2) Procedural Abuse

	The present last call is actually the fourth that the group has been
presented with. At no time has the group rejected OPT-IN or have the
discussions in last call been interpretable as anything other than a narrow
consensus in favor of OPT-IN with the large domain registries and Paul Vixie
of BIND being in favor and others against.

	Instead of forwarding the draft to the IESG a series of stratagems
has been employed to prevent any decision that would be appealable on the
technical merits. A pattern that continues to this day.

	The first Last Call terminated with no decision from the chairs
until a later report stated that the matter had been referred to the DNS
Directorate (see below)

	The second Last Call terminated with no comments raised in
opposition. A chair then stated that the standard on this occasion had been
choosen as a requirement for positive affirmation, and not as had been the
custom of that working group until that date of no opposing comments.

	The lack of statements of support was in large part the result of a
request that had been made by OPTIN opponents to OPTIN proponents to avoid
re-raising what had become a divisive and contentious issue. 

	The third Last Call was confined to the technical issues of opt in.
These were to be discussed before the valoidity of the requirements on which
the proposal is based. Once again the consensus of the working group was in
favor of opt-in.

	The fourth Last Call result has not been announced and it is likely
will never be announced. The clear consensus, nay unanimity! amongst those
parties that operate the class of infrastructure whose needs OPT-IN is meant
to serve is in favor of OPTIN. One of the chairs has suggested though that
such opinions have to be given weight in accordance with the 'expertise' he
accords to the individuals concerned.

	If commercial interest is not going to play a part in the operation
of the IETF then what grounds can there be for 'expertise'. How dare the
claim be made that an academic whose experience of DNS operations is limited
to reading theory and compiling BIND gainsay the expertise of those who keep
the Internet running on a daily basis?

	The opponents of OPTIN have frequently pointed to the IETF policy
that we are all individual contributors and do not speak for our employers,
thus conveniently depriving those of us with responsibilities to our
customers, the ultimate users of the Internet the authority to speak in that
role. They have not however shrunk from using the fact of our employment
against us. Almost every statement I have made on the subject of OPTIN has
been attacked on the grounds of pecuniary interest. OPTIN opponents have
also attempted to silence my dissent by complaining to my employer.

	Finally it has been asserted that this issue has become a an issue
of personalities rather than technical merit. I absolutely concur and in
this regard report that Randy Bush informed me of this fact in the first
DNSEXT meeting I attended, befire I had in fact made any contribution to the
group directly and I am sure before Randy could have any personal knowledge
of either me or my work. Rather than allow me to give my name and company
directly he choose to deliberately and audibly hiss in order to intimidate
me.

	I am not the type of person to be intimidated so easily, but yes the
action and Randy's subsequent refusal to appologise has of course coloured
all the deallings between myself and the group. I conclude from such actions
that Randy Bush has from the start intended to make the DNSEXT group a
hostile environment for participation by people such as myself. In this
respect I believe that Randy Bush has willfully broken the core values of
the IETF, namely inclusiveness in persuit of his own personal agenda.

3) Failure to observe open process

	At one point OPT-IN was refered to the 'DNS Directorate'. This being
a closed body that does not minute its deliberations, this referal however
allegedly proper in terms of IETF process cannot be considered to be an open
process.

	The referal to the DNS Directorate was not notified to the WG in
advance, the first notice that was given was a statement that the
Doirectorate had decided against OPT-IN. The Directorate then composted the
OPT-IN document for a further six months until the WG finaly restarted work
of its own accord. I can find absolutely no record of a report to the WG of
the Directorate input.

	I requested the right to participate in the discussions of the
directorate as someone very familiar with security issues and in particular
the workings of OPT-IN and was refused. That left Steve Bellovin and Derek
Atkins as the only members of the Directorate who were first and foremost
cryptographic security experts.

	Indeed so opaque are the workings of the Directorate that even its
members do not know whether they are members or not. Derek Atkins reports
that he only discovered he was no longer on the directorate through a third
party.

	In conclusion, it is clear that the DNSEXT working Group has done
all that it can on this subject. It is now time for the IESG to consider the
issue on the technical merits.

	If OPTIN is not to proceed they must state whether they believe that
DNSSEC deployment will ever be feasible and if so which parties they believe
are going to support deployment.

		Phill

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