The IETF NomCon Fiasco

Eric Rescorla blogged on this before I got a chance to. He does a good job of setting out the current situation with the IETF NOMCON process.

The short version is that this is a cryptographic protocol that is meant to select ten people at random from a list of eligible volunteers. The problem in this case is that 1) the list was not published as it should have been and 2) there was a person on the list who should not have been there. Due to the design of the cryptographic protocol used this meant that the compiler of the list could have biased the selection process and so has proposed that the process be 'reset' but this also creates a method of biasing the process as it creates a precedent whereby unacceptable outcomes can be avoided by having a 'redo' until the desired outcome is achieved.

I have not seriously analyzed the IETF selection protocol before now but I have always considered it as 'too clever by half'. I come from a country where we use ballot papers and a pencil for every election and have not had a seriously contested outcome for over a century. The same cannot be said for the US where discussion of Florida's 'hanging chads' has been replaced by the question 'can we trust Diebold'.

The superficially random nature of the selection process for the nomination committee is an artful way of disguising the fact that the whole point of the process is to avoid accountability. Academics are fond of tenure, Engineers dislike deadlines. If you allow a group of engineering academics to design an institution for themselves to work in you are unlikely to find that it has strong accountability mechanisms.

Eric is correct in pointing out that the IETF is a volunteer organization. It is not however an amateur organization, or to be more precise the IETF prides itself on the importance of the work that it does and the expertise that it brings to this work. It follows therefore that volunteerism is not an acceptable excuse for amateurism.

The flaw in the IETF protocol is the same one that is faced in real world elections and in most of the academic cryptographic voting schemes. One of the systematic failures of cryptographic voting protocols has been that with rare exceptions they consider the paramount concern to be secrecy of the ballot. In practice this is a very small concern. The point of secrecy is to prevent intimidation of voters or selling of votes. This is certainly one way to rig an election but any attempt at intimidation or vote buying on a large enough scale to affect the vote is going to be noticed and the results would be self correcting.

The two real concerns in electoral systems are 1) auditability and 2) vote suppression. Vote suppression has a long history in the US, the simplest way to rig an election is to stop voters likely to vote for the other party from registering to vote or if unable to prevent them registering stop them getting to the right polling station or if unable to do that discourage them from voting by ensuring that there are not enough voting machines available.

Vote suppression is a real issue but not one that can be fixed using cryptography. The principle concern for the cryptographic protocol therefore is to ensure that the process is auditable.

The critical flaw in the IETF process is the dependence on the list of candidates. If the cryptography is going to be as robust as possible the influence of the organizaers should be minimized. The current process has a critical reliance on the drawing up of the list of candidates. Publishing the list of candidates prior to the discovery of the random seed information is a critical control if the process is to be fair and auditable.

The way to fix the selection scheme is to eliminate the critical dependence on compiling the list. A simple way of doing this is to use a common random seed, a MAC function and the email address of the volunteer to create a score with the top ten scores being the selected members. So the score for alice@example.com would be MAC (seed, "alice@example.com").

The advantage of this scheme is that it is still possible to generate a score even if the list is not generated and published correctly and on time. If a person is left off the list it is still possible to calculate a score for them provided they can prove that they are eligible. If a person is included in the candidate list but is found to be ineligible for any reason their inclusion does not affect the outcome and can be ignored.

The moral here is that cryptography is often a critical part of the solution to real world security requirements but it is a mistake to consider cryptography to be a panacea. Cryptographic protocols that do not take account of real world exceptions turn out to be like cast iron - strong but brittle. The art is to design protocols that are like steel, strong enough and flexible enough for real world needs.