rfc2777.txt

RFC 的详细文档！

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 2777                                      Motorola
Category: Informational                                    February 2000


              Publicly Verifiable Nomcom Random Selection

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a method for making random selections in such
   a way that the unbiased nature of the choice is publicly verifiable.
   As an example, the selection of the voting members of the IETF
   Nominations Committee from the pool of eligible volunteers is used.
   Similar techniques would be applicable to other cases.

Acknowledgement

   Matt Crawford made major contributions to this document.

Table of Contents

   1. Introduction............................................2
   2. General Flow of a Publicly Verifiable Process...........2
   2.1 Determination of the Pool..............................2
   2.2 Publication of the Algorithm...........................2
   2.3 Publication of Selection...............................3
   3. Randomness..............................................3
   3.1 Sources of Randomness..................................3
   3.2 Skew...................................................4
   3.3 Entropy Needed.........................................4
   4. A Suggested Precise Algorithm...........................5
   5. Fully Worked Example....................................6
   6. Security Considerations.................................7
   7.  Reference Code.........................................8
   Appendix: History of NomCom Member Selection..............14
   References................................................15
   Author's Address..........................................15
   Full Copyright Statement..................................16



Eastlake                     Informational                      [Page 1]

RFC 2777              Verifiable Random Selection          February 2000


1. Introduction

   Under the IETF rules, each year 10 persons are randomly selected from
   among the eligible persons who volunteer to be the voting members of
   the nominations committee (NomCom) to nominate members of the
   Internet Engineering Steering Group (IESG) and the Internet
   Architecture Board (IAB) [RFC 2727].  The number of eligible
   volunteers in recent years has varied in the approximate range of 40
   to 60.

   It is highly desireable that the random selection of the voting
   NomCom be done in a unimpeachable fashion so that no reasonable
   charges of bias or favoritism can be brought.  This is for the
   protection of the IETF from bias and protection of the administrator
   of the selection (currently, the appointed non-voting NomCom chair)
   from suspicion of bias.

   A method such that public information will enable any person to
   verify the randomness of the selection meets this criterion.  This
   document gives an example of such a method.

2. General Flow of a Publicly Verifiable Process

   In general, a selection of NomCom members publicly verifiable as
   unbiased or similar selection could follow the three steps given
   below.

2.1 Determination of the Pool

   First, you need to determine the pool from which the selection is to
   be made.

   Volunteers are solicited by the appointed (non-voting) NomCom chair.
   Their names are then passed through the IETF Secretariat to check
   eligibility.  (Current eligibility criteria relate to IETF meeting
   attendance, records of which are maintained by the Secretariat.)  The
   full list of eligible volunteers is made public early enough that
   there is a reasonable time to resolve any disputes as to who should
   be in the pool, probably a week to ten days before the selection.

2.2 Publication of the Algorithm

   The exact algorithm to be used, including the public future sources
   of randomness, is made public.  For example, the members of the final
   list of eligible volunteers are ordered by publicly numbering them,
   several public future sources of randomness such as government run





Eastlake                     Informational                      [Page 2]

RFC 2777              Verifiable Random Selection          February 2000


   lotteries are specified, and an exact algorithm is specified whereby
   eligible volunteers are selected based on a strong hash function [RFC
   1750] of these future sources of randomness.

2.3 Publication of Selection

   When the prespecified sources of randomness produce their output,
   those values plus a summary of the execution of the algorithm for
   selection should be announced so that anyone can verify that the
   correct randomness source values were used and the algorithm properly
   executed.  A cut off time for any complaint that the algorithm was
   run with the wrong inputs or not faithfully executed should be
   specified to finalize the output and provide a stable NomCom.

3. Randomness

   The crux of the unbiased nature of the selection is that it is based
   exactly on random information which will be revealed in the future
   and thus can not be known to the person specifying the algorithm by
   which that random information will be used to select the NomCom
   members.   The random information must be such that it will be
   publicly revealed in a timely fashion.

   The random sources should not include anything that any reasonable
   person would believe to be under the control or influence of the IETF
   or its components, such as IETF meeting attendance statistics,
   numbers of documents issued, or the like.

3.1 Sources of Randomness

   Examples of good information to use are lottery winning numbers for
   specified runnings of specified lotteries.  Particularly for
   government run lotteries, great care is usually taken to see that
   they produce random quantities.  Even in the unlikely case one were
   to have been rigged, it would almost certainly be in connection with
   winning money in the lottery, not in connection with IETF use.

   Other possibilities are such things as the closing price of a stock
   on a particular day, daily balance in the US Treasury on a specified
   day, the volume of trading on the New York Stock exchange on a
   specified day, etc. (However, the reference code given below will not
   handle integers that are too large.) Sporting events can be used but
   only with care to specify exactly what quantities are being presumed
   random and what will be done if they are cancelled or delayed.

   It is important that the last source of randomness, chronologically,
   produce a substantial amount of the entropy needed.  If most of the
   randomness has come from the earlier of the specified sources, and



Eastlake                     Informational                      [Page 3]

RFC 2777              Verifiable Random Selection          February 2000


   someone has even limited influence on the final source, they might do
   an exhaustive analysis and exert such influence so as to bias the
   selection in the direction they wanted.  Thus it is best for the last
   source to be an especially strong and unbiased source of a large
   amount of randomness such as a government run lottery.

   It is best not to use too many different sources.  Every additional
   source increases the probability that it might be delayed or
   cancelled calling into play contingency plans or, worst of all,
   possibly creating a situation that was not anticipated.  This would
   either require arbitrary judgement by the Nomcom chair, defeating the
   randomness of the selection, or a re-run with a new set of sources,
   causing much delay.  Probably a good number of sources is three.

3.2 Skew

   Many of the sources of randomness suggested above produce data which
   is not uniformly distributed.  This is certainly true of stock prices
   and horse race results, for example.  However, use of a strong mixing
   function [RFC 1750] will extract the available entropy and produce a
   hash value whose bits, remainder modulo a small divisor, etc., are
   uniformly distributed.

3.3 Entropy Needed

   What we are doing is selection N items without replacement from a
   population of P items.  The number of different ways to do this is as
   follows, where "!" represents the factorial function:

                                    P!
                               -------------
                               N! * (P - N)!

   To do this in a completely random fashion requires as many random
   bits as the logarithm base 2 of that quantity.  Some sample
   calculated approximate number of random bits for the selection of 10
   nomcom members from various pool sizes is given below:

                  Random Selection of Ten Items From Pool

   Pool size     20   25   30   35   40   50   60   75  100
   Bits needed   18   22   25   28   30   34   37   40   44

   Using an inadequate number of bits means that not all of the possible
   selections would be available.  For a substantially inadequate amount
   of entropy, there would be substantial correlations between the
   selection of two members of the pool, for example.  However, as a
   practical matter, for pool sizes likely to be encountered in IETF



Eastlake                     Informational                      [Page 4]

RFC 2777              Verifiable Random Selection          February 2000


   nomcom membership selection, 40 bits of entropy should always be
   adequate.  Even if there is a large pool and theoretically more bits
   are needed for complete randomness, 40 bits of entropy will assure
   that the probability of selection of each pool member differs from
   that of other pool members, the correlation between the selection of
   any pair of pool members, etc., differs only insignificantly from
   that for completely random selection.

   An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more
   than that number of bits of entropy.  However, this is three times
   what is likely to ever been needed for IETF nomcom membership
   selection.

4. A Suggested Precise Algorithm

   It is important that a precise algorithm be given for mixing the
   random sources specified and making the selection based thereon.
   Sources suggested above each produce either a single positive number
   (i.e., closing price for a stock) or a small set of positive numbers
   (many lotteries provide 6 numbers in the range of 1 through 40 or the
   like, a sporting event could produce the scores of two teams, etc.).
   A sample precise algorithm is as follows:

   For each source producing multiple numeric values, represent each as
   a decimal number terminated by a period (or with a period separating
   the whole from the fractional part) and without leading zeroes
   (except for a single leading zero if the integer part is zero) or
   trailing zeroes after the period.  Order them from smallest to the
   largest and concatenate them and follow the results by a "/".  For
   each source producing a single number, simply represent it as above
   with a trailing "/".  At this point you have a string for each
   source, say s1/, s2/, ...  Concatenate these strings in a pre-
   specified order and represent each character as its ASCII code
   producing s1/s2/.../.

   You can then produce a sequence of random values derived from a
   strong mixing of these sources by calculating the MD5 hash [RFC 1321]
   of this string prefixed and suffixed with a zero byte for the first
   value, the string prefixed and suffixed by a 0x01 byte for the second
   value, etc.  Treat each of these derived random values as a positive
   multiprecision integer.  If there are P eligible volunteers, select
   the first voting member by dividing the first derived random value by
   P and using the remainder plus one as the position of the selectee in
   the ordered list or volunteers.  Select the second voting member by
   dividing the second derived random value by P-1 and using the
   remainder plus one as the position of the selectee in the list with
   the first selectee eliminated.  Etc.




Eastlake                     Informational                      [Page 5]

RFC 2777              Verifiable Random Selection          February 2000


   It is recommended that alphanumeric random sources be avoided due to
   the greater difficulty in canonicalizing them in an independently
   repeatable fashion; however, if any are used, all white space,
   punctuation, and special characters should be removed and all letters
   set to upper case. This will leave only an unbroken sequence of
   letters A-Z and digits 0-9 which can be treated as a canonicalized
   number above and suffixed with a "/".

5. Fully Worked Example

   Assume the following ordered list of 25 eligible volunteers is
   published in advance of selection:

         1. John         11. Pollyanna       21. Pride