RE: Now there seems to be lack of communicaiton here...

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: RE: Now there seems to be lack of communicaiton here...

Actually the scheme I propose does not depend on pre-announcement of the list, only providing a proof of registration.

 

I have not worked out exactly to avoid every attack but there is certainly no need to publish everyone's email address - although it is odd that you would mention that as the IETF is currently publishing my telephone number I gave when registering for a previous IETF. Certainly every selected member of NOMCON has to be reachable by email.

 

All you require is a unique identifier. It could be the participant's name. If a person is registered twice and this is detected then you use the name that occurs first in some cannonical ordering.

 

The registration mechanism could be a Web form that you fill in that causes a receipt to be sent to the email address specified. That way a registrant has a proof that they registered and can use that to challenge the list.

 

 

---

From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake@xxxxxxxxxxxx]
Sent: Saturday, September 02, 2006 6:39 PM
To: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...

Depends what you mean by "it". The overall process may have broke in this case but 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. The one you suggested depends on pre-announcement of the email address of every volunteer. 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.

 

Donald

---

From: Hallam-Baker, Phillip [mailto:pbaker@xxxxxxxxxxxx]
Sent: Saturday, September 02, 2006 10:00 AM
To: John C Klensin; Ned Freed; Eastlake III Donald-LDE008
Cc: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...

If it ain't broke? How much more evidence of being broke do we need?

The bug here is that the process is insufficiently robust under operator error.

That is broke.

The underlying problem here is the lack of auditability in the process.

There is a simple fix here, eliminate the dependency on the list ordering and the system does not have such a critical dependence on the operator.

Again nobody is claiming anything dishonest has happened here. The concern is that the accident could be repeated on purpose in the future to exclude undesirable candidates. Having spent part of last month watching this attempted in Alabama it is a real concern.

When something is broke admit the fact. Prattling on about not fixing what aint broke only makes people angry.


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

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf