STS Teleconference - October 31, 2006

Topics for December? Yes. End-to-end crypto systems as well? Maybe. Are we going to introduce resolutions for all these? Wireless - if appropriate. Security Documentation already in resolution. Setup Validation - maybe not necessary.

Setup validation is a precursor to IDV discussion. Not including requirements for electronic IDV -- should this section be if you know you're going to consider them. [If we say that we only want software independent system, then the electronic IDV is out.]

Major confusion about deliverables and requirements that are due for VVSG 2007. We need test bases to implement standards we have more than revised standards. Committee has been operating under the assumption that July 2007 is the target date new sets of resolutions and requirements to replace 2005. Memo sent out last summer discussing purpose of TGDC. EAC wants TGDC to do what is best and will secure the election system. This is what STS has been discussing, and software dependent systems have come to the top as having extreme risk.

We do not have adequate tools today to validate that the equipment being used is the same that is being certified. The certification process is incapable of ensuring there are not critical bugs.

We need better information flow and coordination between state's vigorous evaluation process and federal process and requirements. Could use TGDC help, but may be out of our scope. Maybe TGDC could identify where redundant independent testing adds value and where it doesn't - especially open ended testing with security.

As far as December meeting priorities, there appears to be concern with banning software dependent machines - primarily for transition. We also need to think about the public confidence message we send. We need to show them that people are working to improve the processes. If drivers of deployment are economic we may not do any better with deploying non-broken systems than last time. Some machines are easily certified within current resources, others are much more expensive. No amount of money would help us completely evaluate software dependent systems. We are trying to develop a class of systems that can be certified with the resources available.

If there are no funds provided to the states from the federal government, it will be difficult for the jurisdictions to make significant improvements. Members thought we were looking at 2007 to give guidelines to vendors and officials where we were going to go.

Transition plan. Current systems are grand-fathered. When buying new systems after 2010, then you'll have to choose from the ones that are certified. The TGDC was not tasked to make plans and regulations for grand-fathering systems, however, should keep that in mind when making changes.

Each subcommittee will get about 3 hours to present at the December 4 and 5 TGDC meeting. An hour for resolutions will be at the end.

End-to-end Systems

Bill Burr had passed around a note and there has been some email discussion about this topic.

If we're talking about a whole class of innovative systems, the most interesting comments were on the process. If we're talking about end-to-end systems being software independent, David's requirements has that all code had to be public to certify such systems. If we have software independence, end-to-end, Bill's not sure why we have to do this. [David: The evaluation process has to determine whether the system is indeed software independent (checking crypto protocol implement properly). Evaluation has to be done by someone, and the best way to do that is have a security evaluation panel to evaluate security issues and to make sure that panel is not structured the same as the testing labs. Ron: The current feeling of manufacturers may be reluctant to reveal their source code because of how it's written, while manufacturers that are writing newer code with more knowledge on it might be more agreeable. Fear of disclosing code because of trade secrets.]

There's no logical requirement that the code be public because you're not dependent on that code. [John K disagrees. Because you have to have some way to verify that the code in the machine is actually implementing the protocol you think it's implementing, making sure it follows the rules, making sure it doesn't violate voter privacy or giving out information so an attacker can buy votes, and you have reliability issues.] Not having the source code does not mean you can't validate the election.

We don't want to spend duplicate money for doing the software evaluation for end-to-end voting systems the same as you do for the closed boxed DREs.

Should we be drafting separate class and requirements for that class for end-to-end systems or whether we should lump it into a larger innovation class and provide for new systems to be included in that? What else will be in the class? VVPAT, paper opscan, fraud-like opscan device.

David Wagner: What are the 3 biggest things we could be doing to improve security. 1) Mandating software and hardware independent voting systems (banning ones that are software dependent), 2) instituting some kind of security evaluation process, and 3) source code disclosure. Those are in priority order, so the first one is the one I would want most.

Bill's paper was meant to be a short introduction, to sell the concept. Would like to have Bill Jeffrey read this as well as the 3 ballot paper. David Wagner agrees with model, just suggests changes in the evaluation process.

Bill: How do we cope with the new public crypto key systems that are being pushed for federal use? A lot of process things we need answers to. A paring based crypto system. It's not obvious that using a government approved crypto system is so important. Technology is evolving and we'd like to have some kind of strong evaluation process. Innovation class is open. If someone can make software dependent systems work, we'll listen to them.

The evaluation process only validates that the systems are certifiable at some high level of security.

With the new innovation classes, we need to provide a lot of publicly disclosed information. New innovation class would definitely have a generic high level state of requirements. More specific requirements would be architecture dependent.

HAVA requires that standards be examined every four years. There needs to be some sort of change process for adding modules. Maybe we should mention this at the December meeting. We may need to update the VVSG on a continuing basis.

Under new model, the way to have an IDV system certified is to go through the new innovation process we're discussing. We need to get the high level requirements right, and then the vendor could design something and bring it to the table.

We need manufacturer push instead of NIST pull on this stuff. States should ask if there are classes that are not currently on the market that they would like to see. Bill needs to write section at the end to invite vendors to write proposals and that the burden would be on them.

We need to have a budget set aside to support innovation. For either evaluation process or for people designing new innovations. NIST needs to stay away for designing. We should be looking at the evaluation process.

We need to have as much discussion as possible with the TGDC before the December meeting.

Will there be an issue about whether or not we need to write VVSG 07 or whether we should be looking at other testing issues instead? Steve believes that will be the case, and thought that was already settled. Steve please send out his last summer memo regarding this issue.

When you talk about TGDC not doing design work, I agree. But please elaborate exactly what you mean. When talking about design election mark up language for IDV or the protocol between devices, or pairing classes is inappropriate for this committee. Steve things that when discussing interfaces that work reliably, not doing a complete system. This should be a continuing discussion about interfaces. This also goes to software, and better firewalls.

This is a huge issue if the TGDC members decide to do something besides the VVSG 2007. We need to discuss this!

Next meeting is Thursday, November 9, 2006.