The DNSO supports an Internet infrastructure component; the
membership of the DNSO, the constituencies, and the Names Council
will be *required* to be from widely distributed geographical
regions.
So, either participation the DNSO becomes a very expensive
proposition involving lots of travel, or the DNSO works out online
methods of conducting business. Many people have commented that
the former option is not only very undesirable, but absurd.
The current draft application contains the following short snippet
germane to this point:
The DNSO, the Names Council and each of the constituencies will
establish on-line methods of meeting and conducting ballots.
The DNSO will develop procedures for its deliberations. Applicable
IETF procedures will be examined as a possible model.
I would like to expand this text in the application.
The IETF has a general rule that online discussion has precedence
over physical meetings. That is, a decision reached at a physical
IETF working group meeting must be ratified on the associated mailing
list.
I propose that we formalize the IETF rule in the application, as
well, and stipulate that all substantive decisions of the DNSO or any
of its components must be reached through online decision procedures.
This will guarantee that the ability to pay for travel will not be a
prerequisite for effective participation.
In particular, I propose the following language:
The DNSO, the Names Council and each of the constituencies will
establish online methods of meeting and conducting ballots. All
official decisions of any of these bodies will be ratified through
such online means.
The DNSO will develop procedures for its deliberations. Applicable
IETF procedures will be examined as a possible model.
This is a non-trivial addition, and it has serious implications, the
most important of which is that the "online means" need to be
available and working before any official decision of the DNSO can be
made.
The rest of this note discusses some of the general issues, and then
makes a specific proposal. I appologize in advance for the length,
but it should be an easy read...
Decision Procedures
A decision procedure is a procedure for turning information into a
decision. An election is a decision procedure composed of two parts:
a polling procedure, which gathers information (eg, "all in favor of
the measure raise their hands"); and a decision rule ("the measure
passes if more than 50% of those present raise their hand").
Without the decision rule the election is simply a "straw poll" that
gathers information.
Note that a decision rule implies some kind of binding authority or
agreement -- if the parties involved don't have some enforcement
discipline that binds them to the rule, it is meaningless. In an
organizational context, the binding is frequently through membership
-- joining an organization is an implicit or explicit agreement to
abide by the decision rules of the organization: if you don't agree
to the decisions of your organization, you leave the organization.
[In the case of the DNSO, in my opinion there should be an explicit
membership agreement that specifies these ground rules. Such an
explicit agreement also fits well with the requirements for legal
identification, discussed further below.]
There are several examples that present useful input to our case: the
IETF, informal small group votes (as exemplified in the Monterrey
meeting), standard corporate voting procedures (as exemplified in the
INTA proposal), an attempt to implement online voting in civil
elections in New Zealand, and so on.
The IETF Model
The decision procedure used in the IETF is "rough consensus". Rough
consensus is an amazingly effective and highly evolved mechanism that
has served the IETF very well. The IETF procedures are not as widely
understood as some of the others I will mention, so I will discuss it
in a bit of detail.
Rough consensus is explicitly imprecise. The information gathering
phase is done by designated individuals (working group chairs), who
determine "the sense of the group" through whatever methods they
chose -- straw polls, "humming", asking who disagrees. The decision
rule is similarly imprecise: basically, it's just that "most people
agree".
This fuzziness is mitigated by a very important factor: while it is
hard to detect rough consensus, it is easy to check for its
non-existence: If more than a tiny fraction of members protest, it is
obvious you don't have rough consesus. Therefore, in practice, signs
of non-consensus are what people look for.
An important corollary of this fact is that if you don't speak up,
you are assumed to agree -- in other words: "silence is consent".
Therefore, unfettered speech is a prerequisite for fairness in the
rough consensus paradigm.
Much of the power/responsibility for decision making is in the heads
of the WG chairs. In a different environment this could lead to
serious abuses that are largely absent in the IETF. The IETF does
have a series of appeal steps to backstop the WG chair, if problems
arise [1], but it is well-understood that success really depends on
the quality and integrity of the WG chairs.
Another important characteristic of rough consensus is its
efficiency. Technical design is a process of constant
decision-making, and technical design by a group absolutely requires
very efficient decision processes. The informal assessment of rough
consensus by a WG chair is very quick, and therefore, little time is
lost in formal procedures. This is especially important in light of
the fact that the IETF does most of its work over email lists -- a
more formal decision process would bog down in the variable time
delays inherent to communication via email.
Independent of problems of abuse, there are two important weaknesses
of rough consensus as a decision process. First, by definition it
can't decide between multiple competing proposals with nearly the
same support [2] -- for example, it is not well-suited for use in
selecting officers. Second, it is weak in cases where formal
accountability is important -- it would be hard to prove in court
that a rough consensus decision by a WG chair "really" represented
the will of the group.
Most of the time in the IETF there are technical reasons for one
decision over another, and those reasons usually come out after
sufficient discussion -- very frequently, differences are resolved on
fairly objective grounds. Thus rough consensus works most of the
time. This creates a steady background of resolved differences, a
momentum which contributes to the well-known culture of consensus in
the IETF.
Small Group Polling
In Monterrey we used rough consensus methods, but they didn't always
work. When they broke down we went to straw polls -- ad hoc votes
designed more to gather information than to make a decision. [3]
The nature of these straw polls varied -- sometimes a careful count
of hands was made, sometimes it was "all in favor say 'aye'",
sometimes it was an IETF-style "all in favor hum". These different
techniques varied in formality, but they all are species of what I
will call "small group polling".
The important characteristic of SGP as a decision procedure is its
transparency: everybody involved sees everybody else's vote;
everybody involved can check the count. The mechanics are completely
visible, and it is hard to question the result. It is easy to get
complete accountability by extending using a recorded roll call vote
as the mechanism. [Voting by roll call also works very well over
telephones, where you can't see people waving hands.]
The INTA "Standard Corporate" Model
The INTA document presents a concrete example of a conventional
corporate decision procedure. Decisions are made through votes at
meetings, the decision rules are specified in each case in the
bylaws, and the bylaws also define the membership structure that
provides the binding of participants to the decision rules. While
there is mention of online meetings in the INTA document, in practice
all the discussion is predicated on physical meetings.
The size and dispersion of the membership of the INTA version of the
DNSO make it impractical to use small group techniques -- it is hard
to accurately count hands when you have a thousand people in a room,
and a roll call vote would be very boring to sit through.
Instead, the INTA model makes use of standard corporate techniques --
proxies, voting by physical mail, etc. Usually these procedures are
contracted to an independent trusted third party to handle the
voting, both for efficiency, and to deal with the problem of
dishonest counting of votes. This is, in general, a large scale,
complex, and expensive decision procedure.
Governmental Elections
Election of public officials is a complex affair in practice. It is
an official function of government, and there are great concerns
about voter fraud. At least in the United States, voters are
required to register to vote, and provide positive identification at
polling places. An elaborate series of checks are in place to
guarantee accurate counts. The whole procedure is complicated
greatly by the fact that secret ballots are required.
There are some current experiments in online voting for Government
elections -- the New Zealand Electronic Electoral Trial experiment at
http://www.polemic.net/nzeet.html is an example. You register, get a
"Voter Identification Number", and vote via a web interface. The
site does not discuss in any depth the complex issues of
identification and validation of the vote, or what measures are in
place to guard against voter fraud. [As a person involved in
computer security, these are the very first questions that come to my
mind.] While these experiments are interesting, the requirements are
so different that the underlying mechanism does not seem applicable
to our case. However, the web interface might well be something we
wish to emulate.
General Issues Concerning Online Voting
The obvious way to vote on the Internet is via email. An alternative
would be some kind of web interface, but email is ubiquitous, easy to
use, familiar to everyone connected to the Internet, and could be
used in many situations where a web interface would be hard to
implement. So, for this discussion I will concentrate on email as a
basic mechanism, and leave a web interface to a later time.
The biggest issue with online voting over email is the difficulty
of verifying identity. More than that -- it is trivially easy to
create fake identities, and it is possible, with varying degrees of
difficulty, to spoof already established identities. And some kinds
of voting (secret ballot, for example) are either difficult to
implement, or require the involvement of a Trusted Third Party.
The second major problem with email is that information in email
messages travels the public internet, and, without strong measures,
must be considered public knowledge. Without these measures,
therefore, privacy cannot be guaranteed, and, once again, secret
ballots cannot be conducted.
These problems are solvable using encryption and digital signatures.
However, encryption and signatures involve much greater complexity at
the user level, a public key infrastructure, and dealing with the
uncertainity of international encryption policy. Our lives would be
much simpler if we did not need to rely on encryption [4].
Fortunately, if you dispense with secret ballots it is relatively easy to
implement a relatively secure, reliable, and accountable online
voting system, because small group tally voting works quite well over
email. Furthermore, if you use a recorded roll call procedure, the
system can scale to much larger sizes than could be handled in a
physical meeting.
Online Small Group Polling
This is easy: consider a small online group context -- a small
mailing list with perhaps a dozen participants, for example. Someone
calls for a vote. Everybody sends their vote to the list. Everybody
sees all the votes. Someone (anyone) tallies up the votes; everyone
can check the count.
This is simple and straighforward, and works perfectly well.
There are theoretical attacks, but they require completely
unreasonable assumptions [5]. It would work fine for the Names
Council, for example. If the email exchanges are on a public,
archived list you get transparency and accountability for free.
The generalization to larger scale is also straightforward. Here is
a concrete proposal:
Proposed Formal DNSO Online Polling Procedure
One of the requirements of being a member of the DNSO is that the
member have a legally verifiable identity. At the time the identity
is verified we also require a member to supply an email address that
will be their voting address -- generally the email address of the
individual authorized to cast that member's vote. That email
address will also be subscribed to one or more mailing lists through
which official announcements will be made. This requirement takes
care of the verification of identity, and the problem of creation of
false identities. The problem of spoofing of known identities does
exist, but it is substantially mitigated by the factor of public
exposure, mentioned above.
When it is time for a formal election a ballot is prepared, posted on the
DNSO web site, and emailed to each member. The member should
compare the emailed ballot with the posted ballot, edit in the
appropriate mark, and send the ballot back to the DNSO email address
devoted to collecting ballots for that election.
An blank email ballot would look something like this:
Dec 26, 1998 Sample DNSO Ballot.
Edit this ballot to put an "X" in the spot appropriate
for your choice in the measures below, and return it to
"elections@dnso.org".
1. Should new gTLDs be added to the root?
Yes [ ]
No [ ]
Filled out, it would look like this:
Dec 26, 1998 Sample DNSO Ballot.
Edit this ballot to put an "X" in the spot appropriate
for your choice in the measures below, and return it to
"elections@dnso.org".
1. Should new gTLDs be added to the root?
Yes [X]
No [ ]
A standard format for the ballots allows automatic processing of the
results.
The filled out ballot would be mailed to, for example,
"elections@dnso.org", and every single returned ballot would be
posted on the web at the dnso site. Thus every voter can verify 1)
that their ballot was correctly received; and 2) that the tally was
done correctly. Every voter is also reasonably assured that every
other voter sees the same information. Furthermore, any voter who
was not sent a ballot would be aware of the fact, and could protest
publically.
There are some end cases that must be dealt with. For example,
someone could try to invalidate the vote by waiting until the last
minute to send in a ballot, and then protest that their vote was
altered. This is a delaying tactic that could be rather disruptive.
Another problem occurs when someone sends in a vote, sees their vote
on the web site, and believes (legitimately or illegitmately) that
the vote has been altered, and wants to change it.
These problems, and some others, are taken care of by the following
additions to the procedure. First, the voting is divided into two
phases. The first phase collects the votes; the second phase is a
verification phase. During the first phase you can send as many
ballots as you wish, up until the end of the first phase -- the last
ballot received is the one that has effect. This allows a voter to
be sure that their vote is correct, and allows them to correct it if
it isn't. Every time a ballot is submitted, the voter gets a
copy in reply.
At the end of the first phase no more votes are accepted, and phase
two starts. The preliminary results are posted, along with every
voters final ballot. During phase two voters have the opportunity to
protest their vote, and the polling officer may require proof of
identity in extreme cases. In general, however, if the voting is
done carefully and honestly, there should be very few protests. (If
the vote is tallied dishonestly, there should be large numbers of
protests during phase two).
Finally, at the end of phase 2, the final results are posted.
Protests after the end of phase 2 must be ignored.
Because of the delays in email, and changes in time zone around the
world, a vote like this should be given a couple of weeks to
complete, to give people time to send in their ballots and verify
them. Still, the time scales compare favorably with a paper ballot
sent via the postal service. The time scale could of course be
adjusted -- a formal vote of a small group could be complete in a
day or two. A web interface might be somewhat more efficient, but
the distributed nature of the electorate is a fundamental problem
that no interface will cure.
As described, the proposal is not a decision procedure -- it is
simply a polling mechanism, to which the standard electoral decision
rules could be applied ("simple majority", "two thirds majority",
"most votes wins", etc).
Interestingly enough, the most salient point about this procedure is
not the technology, but is rather the way that trust and verification
are handled. What makes it work is the fact that it is so public,
and that is essentially independent of a particular technology.
Incidentally, this proposal does not theoretical -- it is based
originally on mechanisms used in Usenet for creation of new
newsgroups. Dan Busarow developed those mechanisms further, and
produced software that manages the vote counting automatically. PAB
and CORE (both online organizations distributed worldwide) have used
this software successfully many times, both for the development of
policy and the election of officers.
Since an implementation is available, either to use directly or to
use as a model, there would be no difficulty in the DNSO having
online decisions essentially from the beginning.
================================================================
[1] When there are differences that can't be resolved they usually
(but not always) stem from ultimately non-technical sources. The
IETF provides a large safety valve for such disagreements -- if you
don't like a protocol, you can always go start your own working group
to come up with an alternate protocol, more to your liking, and let
the market of ideas choose the winner. Sometimes there is no winner,
and multiple standards coexist. The IETF explicitly allows this --
the standards it develops are all voluntary standards.
[2] Sometimes simply chosing is more important than making the "best"
choice -- if one is being run down by a train, one does not want to
spend time debating whether it is better to jump to the left or the
right side of the tracks.
[3] Sometimes the polls were poorly constructed, in that the
alternatives were not well defined, or overlapped; and the
interpretation of the information was problematic. Note that in
Monterrey we faced an obvious difficulty using votes as a decision
procedure -- it would have required a commonly agreed on decision
rule, which would in turn would have required a defined membership
agreement. The obvious sequence in forming an organization is that
you must reach *consensus* on the decision rules before you can make
any other decisions.
[4] This is one area where web technology has an advantage, because
SSL is fairly widely distributed. But political difficulties remain,
web technology is not as ubiquitous as email, and the integration
with mail lists is not there.
[5] The security of voting protocols comes up in the cryptotgraphy
literature [caveat: I am by no means an expert in cryptography]. For
an example, the procedure we just described is theoretically
susceptible to a well-known attack called a "man-in-the-middle" (MITM)
attack: Suppose a committee member "Alice" is communicating with a
committee mailing list "List". The Man in the Middle, (traditionally
known as "Mallet") intercepts all messages Alice sends to List, and
all messages that List sends to Alice. Thus, Mallet could alter
Alice's vote, and alter all messages that List sends back, so that
Alice will never detect the alteration. Mallet would likely be the
mailing list operator, in this case, and could completely substitute
Mallet's votes for Alice's votes.
In the extreme case, Mallet intercepts ALL messages to and from the
list, and creates an illusory result for ALL committee members --
every committee member would believe that every other committee
member had voted the way Mallet set things up.
However, these kind of attacks are largely irrelevant to our case,
because they assume that the email vote is the only way that Alice
and List communicate. In the real world committee members would have
other communication channels by which they would verify results --
telephone, occasional personal meetings, things posted on web sites,
physical mail. Every one of these can be spoofed as well -- how do
you really know that the person you met at Monterrey who introduced
himself as "Kent Crispin" is *really* Kent Crispin? -- but in
practice we don't worry abut such things.
Cryptographic protocols are always described in terms of particular
communication channels, and there is always an implicit assumption
that the given channels are the only ones involved. It's obvious
that this assumption generally doesn't apply in our case.
Nonetheless, it is important to keep in mind that the requirement
that the polling mechanism operate in open view to the voting public
is an important one.
-- Kent Crispin, PAB Chair "Do good, and you'll be kent@songbird.com lonesome." -- Mark Twain