Eastlake III Donald-LDE008 wrote:
the "it" referred to in the message you were responding to
is the "cryptographic" part of the process. The one in RFC
3797 depends on pre-announcement of the ordered list of
volunteers.
Just for fun I've added RFC 3797 to an MD5 test suite, works
like a charme, <http://purl.net/xyzzy/src/md5.cmd> (REXX)
Reading RFC 3797 again, I have "float" wrong, I'll fix that.
Maybe a hypothetical 3797bis should get an example covering
also "float". With a sanity check if there is enough entropy.
Decimal digits * 3 could be an approximation, the first digit
for traded stocks is not completely random. The public source
for these input numbers should be given as one or more URLs.
Neither is any more robust than the other against a failure
to make all the information necessary for public verification
available in advance, including the specification of the
source of future randomness.
The "bug" (if any) is related to 3777, not to 3797: If the
IETF secretariat is unable to determine the eligible population
in time the NomCom Chair is in trouble, (s)he must get a final
result (modulo appeals) two months before the 3rd IETF meeting.
Maybe a public list maintained by the secretariat and updated
after each IETF meeting (within two weeks) would help, just
the names and up to five numbers like 66 65 64 63 62. Folks
can then see if they are eligible, and they can discuss errors
as soon as they see them (with the secretariat, and appeals to
ISOC, because IAB and IESG shouldn't interfere in such cases).
RFC 3777 4.15 is not 100% clear. Obviously IAB or IESG members
cannot be NomCom members at the same time. But what if they
volunteer because they know that the random numbers are drawn
after they have resigned from their IAB or IESG seat ? And if
they manage to "forget" to resign they're not eligible, ready.
Under an "assume good faith" doctrine anything in this "tea-pot
tempest" (quoting Randy) makes sense, an IAB member volunteers
because the rules promise that this is a guarantee to get no
other job, several screw-ups between the secretariat and some
volunteers, an announcement sent too late caused by another
hiccup, an RO asking for advice how to fix it, and using the
(intuitively) most conservative approach "reset". But RFC 3797
defines that "most conservative" would be "draw next number" -
which doesn't cover the case "announcement sent after input
random numbers are already determined".
Publishing the complete list two days after the random input
numbers are drawn is a hopeless case. With "secret volunteers"
the result could be manipulated, with a reset an "undesirable"
result could be vetoed. Whatever the RO does, (s)he loses. :-(
If you want to harden the algorithm you could use N, N-1, N-2,
etc. as prefix + suffix for the MD5 input, instead of 0, 1, 2,
etc. Won't help if the list is published too late, with two
consenting "secret volunteers" Zacharias and Abel it would be
possible to silently remove Zacharias from the end of the list,
and add Abel at the begin. Phil's proposal also doesn't help
in this case, it's hopeless. This situation must not happen.
Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf