RE: Fixing the algorithm

"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 01 September 2006 15:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAXD-0001qf-HA; Fri, 01 Sep 2006 11:02:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAXC-0001qB-6Z for ietf@ietf.org; Fri, 01 Sep 2006 11:02:18 -0400
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAXA-0001Lo-Ou for ietf@ietf.org; Fri, 01 Sep 2006 11:02:18 -0400
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k81F2FO9026781; Fri, 1 Sep 2006 08:02:15 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 08:01:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 01 Sep 2006 08:01:38 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD375A2CE0@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Fixing the algorithm
Thread-Index: AcbNQdeb5+K1blU2R6yZ6aQjqWmnlQAAfqnAAAfRlMAAE5o7UAAJgVHW
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Yaakov Stein <yaakov_s@rad.com>, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, IETF-Discussion <ietf@ietf.org>
X-OriginalArrivalTime: 01 Sep 2006 15:01:39.0455 (UTC) FILETIME=[871438F0:01C6CDD7]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc:
Subject: RE: Fixing the algorithm
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1474329677=="
Errors-To: ietf-bounces@ietf.org

This is simply another class of imlementation error.

Things happen, mistakes are made. The question is will people learn from them.

There is an entire litterature of cryptographically secure election protocols that is 100% useless because the wrong requirements are considered. Take a look at recent electoral complaints in venezuela and the us.

In both cases and here the problem is schemes that are too reliant on crypto for security.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Yaakov Stein [mailto:yaakov_s@rad.com]
Sent:	Friday, September 01, 2006 02:42 AM Pacific Standard Time
To:	Hallam-Baker, Phillip; Eastlake III Donald-LDE008; IETF-Discussion
Subject:	RE: Fixing the algorithm


> "The philosophers have analysed the IETF election process in many
ways, the point is to change it"

Actually, the entire process was pre-analyzed in RFC 3979, 
but the analysis was ignored.

As RFC 3797 specifically says, the fair and unbiased method 
is to order the candidates using a random process of sufficient entropy,
and then select the first ten to serve on the NONCOM.
Should one of the 10 turn out to be ineligible or decline to serve
or be disqualified for any reason, the next (11th) candidate is added
to the NONCOM.

As has been stated here on several ocassions, 
the fairness is destroyed by giving any latitude to anyone 
(NONCOM chair, ISOC president, etc) to influence the outcome.

Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf