David Jefferson's Comments on the FEC's Voluntary Standards for Computerized Voting Systems Submitted to the Federal Election Commission, September, 2001 In response to the FEC's Voting System Standards draft Ms. Penelope Bonsal, Director Office of Election Administration Federal Election Commission Dear Penelope, This letter is in respose to the request for comments on proposed revisions to the 1990 national voluntary performance standards for computerized voting systems published in the Federal Register on July 10, 2001. I am sending my personal comments on the VSS, appended below. I am also part of the WOTE '01 group, led by David Chaum and Ron Rivest, and many of my concerns will be reflected in that group's response. I am also on the Board of Directors of the California Voter Foundation, so some of my comments are reflected in Kim Alexander's letter as well. I'd be happy to discuss any of these issues further with you, either formally or informally, if that would be of value. Just let me know. Dr. David Jefferson Compaq Systems Research Center 130 Lytton Ave. Palo Alto, CA 94301 Comments on the FEC Draft Voting Systems Standards David Jefferson September, 2001 Let me first note that there are many things I like about the proposed standards. To the extent I have studied them, they are on the whole excellent. One point that I believe is particularly vital and courageous--since it is a big and possibly costly, but necessary departure from past standards--is the requirement that any Internet voting system must be re-examined annually to see if they should remain certified. And there are many other points on which I think great progress has been made. However, as is usually the case in a document like this, there is no time or need to say much about all of the places where I agree with the document. What I am appending, obviously, is my list of concerns--where I think it does not go far enough to safeguard election security. 1) Extend the comment deadline: My strongest recommendation is that the deadline for commenting on the VSS, Sept. 10, 2001, should be extended, perhaps to Dec. 31. The VSS document is very lengthy and technical, but has been public for only 60 days, and only during the maximally inconvenient summer period when people are on vacation. Under the circumstances, 60 days does not seem long enough for all of the relevant parties to study and make considered comments. I personally feel very rushed on this schedule, and I have been part of the process and knew more or less what to expect! Ideally, my response would have been more like 20 pages, but in this time frame these general comments are all I can manage. In addition, I want to point out that the computing security community has finally begun paying attention to election security issues, and there is a large amount of new work and new expertise that should be considered. A more extended comments period would give this vital community time to digest the standard and respond appropriately. See David Chaum's letter. 2) Continuous standards process: The standards process for electronic and Internet voting systems should be made continuous, i.e. the VSS process should not end for the foreseeable future. All digital technology is changing with tremendous speed, and digital voting technology will be no different. No standards written today are likely to remain reasonable for even 4 years; and some standards that cannot be written today (e.g. for remote Internet voting--see 3 below) might become reasonable to contemplate at that time. As heavy a process as that may seem, a continuous standards process is the only way to prevent the current proposed standard from either stifling innovation or freezing in outmoded security technologies. 3) Remove remote Internet voting standards: The proposed standards for remote Internet voting should be removed from the VSS document entirely at this point. There is general agreement in the technical community that the security problems with remote Internet voting are many and profound, and not likely to be remedied satisfactorily any time soon. I realize that the standards are written in anticipation of the day when security technology and infrastructure improves. But if standards are published now for remote Internet voting, before it is actually possible to meet them, vendors will surely endeavor to make the case that because the FEC standards exist, it must be possible to satisfy them. It is just to early for even proposed standards on remote Internet voting. Instead, the FEC should create a continuous standards process, (see 2 above) and add standards for remote Internet voting at some future date when and if technology permits. 4) Operation in the face of total communication failure: Pollsite Internet voting systems should be required to be able to operate normally, with no interruption of service or attention by poll workers, even if all Internet communication is lost and is never re-established for the duration of the election. In effect this requirement would means that pollsite Internet voting systems must be able to behave as DRE systems when pollsite Internet access is down or under attack, etc. In fact, poll site Internet voting systems would reduce to simply a type of DRE systems, i.e. those that have the capability of securely sending votes back to the county frequently during election day, rather than just once at the end. The difference between pollsite Internet voting and DRE systems is rather small, in my opinion. 5) Public source code: In all electronic voting systems or subsystems, I believe that all software, firmware, scripts, and design documents that have any relevance to the security of the election process should be "public source", i.e. the source code should be open to the public for inspection. It may still be proprietary, in that patent, copyright, and perhaps other intellectual property rights may be held privately, and licensing restrictions may be imposed upon its use. But the actual source code of the software should be open. In particular, this requirement for public source code must apply to all security-relevant code, including operating systems, device drivers, browsers, and other code which, even though "off the shelf", and notwithstanding the fact that it might be a widely-used product, might nonetheless have security holes that endanger the security of the election. 6) Public design documents: The design, specification and API documents for all components, hardware and software, of a voting system should be available to the public. These documents should be detailed enough that anyone in the business of building similar systems could create new equipment to interoperate or replace the original systems. In other words, vendors should not be able to exclude competition on the basis of design secrecy (though exclusion on the basis of patent protection is, of course, permitted); and vendors can, of course, compete on other bases, such as functionality, innovation, service, price, etc. 7) No single point of failure: There should be no single point of failure in a precinct. This standard is actually mentioned in the VSS document, in the one-sentence section 4.6.1 (which is a software section, so the requirement is mislocated).We do not want the transition from paper to electronic voting systems to lead to much greater accuracy, but much less reliability! An election should be able to be conducted normally despite the total failure of any single piece of equipment at a precinct. For example, the ability to continue with total loss of Internet access (4 above) can be interpreted in this light. Similar comments might be made about power failure requirements (e.g. require battery backup and/or spare batteries). Likewise, the small but sometimes vital pieces of equipment that may be part of some voting systems (e.g. printers, scanners, modems, hubs, clerk's computers, etc.) should be required to be duplicated, and their consumables (paper, ink cartridges, batteries, etc.) should all have spares.