Technical Guidelines Development Committee (TGDC)

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee* Teleconference
July 10, 2007, 10:30 a.m.

Draft Minutes

Agenda

1) Administrative Updates
2) Discussion of SI and VVPR requirements (background material below)
3) Topics for upcoming STS calls
4) Other items
5) Next STS call Tuesday, June 26th at 10:30AM.

Attendees: Allan Eustis, Wendy Havens, Whitney Quesenbery. Ron Rivest, Alicia Clay, Sharon Laskowski, Matt Masterson (EAC), Commissioner Donetta Davidson (EAC), Barbara Guttman, Angela Orbaugh, Nelson Hastings, Bill Burr, Nelson Hastings, John Kelsey, Quinh Dang, David Wagner, Helen Purcell, John Wack.

Administrative Updates:

· July 3, 2007 TGDC plenary teleconference has been rescheduled for August 17, 2007 beginning at 11:30 EDT. The extra time will allow NIST to review the HF benchmark data for accuracy and completeness. Planed edits to the HF Report and reviews by additional researchers should make the data understandable and relevant to the election community.

· The final VVSG draft document should be out to TGDC members in early August. We are making final changes by July 20, 2007.

Discussion of SI and VVPR requirements (Ron Rivest):

· Use of paper records or IVVR records. Recommendation to elevate requirements to be more general than just applying to paper. WQ explained: paper is just a specific implementation. Everything else about SI requirements is results or goals (must be useful for auditing etc.) Making it VVPR is a serious implementation limitation and causes many accessibility problems.

· BG commended for synthesizing issues (See below). Looking for performance standards versus design standards.

· Not many examples evident of SI that would not be paper and not in the innovation class.

· BG reviewed her approach: to look at the essence of SI without limiting the choices to paper. What is it we are trying to accomplish with SI in a technology-independent manner? (She reviewed SI and IVVR requirements. See 1.2A and B below). Election officials must be able to review without technology.

· Discussion of durability, privacy and tamper evident requirements.

· HP question- How does this support innovation unless it is in the innovation section?

· BG: Systems using innovation an be classified into two bins: (1) Using a security architecture envisioned here with count and method for auditing count, and (2) voting systems such as cryptographic based systems. (These go through innovation class review).

· If someone comes up with a better way of “doing paper” that is more accessible or usable, then we allow for it in (1) assuming the capability of an independent audit.

· HP- this is hard to understand because there is still no defined system as an example.

· RR: is there a clear process for vendors to decider how his/her system should be evaluated (IVVR or innovation class)? BG: Yes can they meet IVVR is the threshold.

· RR posed questions on chapters 2.2 and 2.3. Proposed that all of the requirements in 2.3 get added to 2.2 with slight rewordings to make them refer to IVVR instead of paper. Most of them have to do with information content instead of paper. BG will go through and extrapolate the requirements up. DW agrees. Same issues apply to all systems.

· JK: auditing requirements specific to paper in 2.2. and 2.3 are specific to cut sheet or paper roll systems. One concern is experience of community with paper based voting systems. We may miss some important requirements when we try to map the paper requirements onto all systems.

· BG: Some risk but paper has drawbacks. DW: The drawback is using a physical medium. BG: Accessibility problems will cross into any print media.

· JK: We know limitations of paper and can write requirements to address these.

· WQ: Some of the attempts (requirements’) to address the paper limitations have violated other requirements. Solution creates more problems.

· Discussion of OEVT, durability and security assumptions. Review of tamper evident requirement.

· BG: Will also go through chapters 2.4 and 2.5 to elevate all requirements not tied to a specific technology. RR: Would like to hear from HF on the suggested changes once they are made- probably the end of next week.

· DW pointed out risk of leaving in an inadvertent loop hole. We need to read carefully, for example to pertain to the same record for each requirement. BG: Everyone should circulate these examples on the STS list.

· AC: OEVT will not catch all loop holes but with new innovative systems, can we require additional OEVT? DW: OEVT is not right tool because it only catches demonstrable vulnerabilities.

· WQ: In last three elections, the major problems have been the result of design flaws.

· Further discussion of OEVT. DW noted example of not finding voting system vulnerability in time allotted to OEVT testers. The vulnerability may still exist even though it was not demonstrated. We need to scrutinize requirements carefully.

· RR: Some burden on vendors for OEVT with new technology assuring they have done due diligence in security areas.

· RR: Good direction to elevate requirements to IVVR but it needs to be done carefully and well.

· MM: What are other pending topics for resolution by STS. RR: This is the main one and OEVT

· Will have an FAQ for OEVT white paper by August 17h meeting.

Topics for upcoming STS calls (Alicia Clay):

· Will review OEVT next Tuesday at STS Teleconference.

Next STS meeting is scheduled for Tuesday, July 17th. The discussion will be on OEVT.

Meeting adjourned at 11:22.

[* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference discussion is for the purposes of the STS subcommittee of the TGDC to direct NIST and coordinate its voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]

E-Mail from: Barbara Guttman

To: STS

We received a comment about expanding the Audit Architecture/Electronic Records/Paper Records chapters to allow for non-paper solutions. We refer to these as independent voter verifiable records (IVVR). Attached is a draft of what this would look like. The benefit to this approach is to promote innovation for other solutions beyond the current systems. The drawback is the possibility of writing requirements that are too loose and would allow systems to conform without adequate security. Please review this idea and the attached draft for discussion at the 7/10 telecon. (Keep in mind also that non-paper IVVR systems would still go through OEVT.) The key section to review is “General Requirements on Independent Voter Verifiable Records” in what used to be the paper records section. I have included those requirements below, as well. Feel free to circulate ideas on both the overall approach and on improving the general requirements.

1.1 General Requirements on Independent Voter Verifiable Records

Voter verifiable records exist to provide a separate record of the voter’s choices, which can be used to verify the correctness of the electronic record produced by the voting device.

ž 1.2-A Direct verification by voters

Independent voter verifiable systems shall create records that voters can verify without software or other technology with the exception of assistive technology.

Applies to: VVPR voting systems