Re: Voting Security (was: The Next Genaration)

[Kathleen Moriarty <[e-mail]>]

Sent from my mobile device

> On Sep 14, 2019, at 1:19 PM, Joseph Lorenzo Hall <[e-mail]> wrote:
> 
> (I've had this argument dozens maybe hundreds of times, not going to do that here.)

Since you cited yourself and EKR as experts that could work on this, where would you like to have the conversation?  A draft perhaps as a starting point as the IETF likes to do things on list, so maybe timing was bad?  A collection of problems with reasoned responses could be useful if this was taken on as work. Or do you have a paper reference with your thoughts/a response?

Best regards,
Kathleen 

> 
>> On Sat, Sep 14, 2019 at 3:28 AM <[e-mail]> wrote:
>> > 
>> > This is pretty off-topic for IETF, but might be interesting to people.
>> > 
>> > I certainly agree that software independence
>> > (https://en.wikipedia.org/wiki/Software_independence) is a good
>> > objective for voting systems, and hand-counted paper ballots are one
>> > good way to achieve that.
>> 
>> Hand counted paper ballots are the only way, IMHO.
>> 
>> > However, there are voting environments where
>> > they are problematic. Specifically, because the time to hand-count
>> > ballots scales with both the number of ballots and the number of
>> > contests, in places like California where there a large number of
>> > contests per election it can be difficult to do a complete hand-count
>> > in a reasonable period of time.
>> 
>> This depends on what we consider reasonable.  If it takes a month, it 
>> takes a month, just like the good old days.  The wait is a small price to 
>> pay in order to ensure the correct functioning of this critical component 
>> of democracy, difficult or not.
>> 
>> > 
>> > One good alternative is hand-marked optical scan ballots which are
>> > then verified via a risk limiting audit
>> > (https://en.wikipedia.org/wiki/Risk-limiting_audit). This can provide
>> > a much more efficient count that still has software independence up to
>> > a given risk level \alpha.
>> 
>> I, for one, am not really willing to risk optical scan machines having 
>> hardware backdoors in the processor, as has been demonstrated, or easily 
>> manipulated firmware, particularly in the name of expediency.  Further, 
>> this does nothing to address the vectors of vulnerability that lie in the 
>> central tabulators, or the route the data takes from collection point to 
>> tabulation point. The latter is potentially an IETF matter, and if so, 
>> should be addressed with no less fervor than BGP security.
>> 
>> I would cite Bush v Gore, 2000; specifially -19000 votes for Gore in 
>> Volusia County, FL.  Was the vector the optical scan ballot system, the 
>> tabulation system, or a routing MITM?  Tough to know, although the 
>> localization and sneakernet transport system from balloting to tabulation 
>> in FL generally would rule out a routing problem in this instance.  IIRC, 
>> there was a questionable route involved in the Ohio, 2004 discrepancy, 
>> although this could have been manual routing through tunnels that caused 
>> the issue.  Would publicly hand counted paper ballots have prevented these 
>> attacks, potentially 18 years of war, falling behind on climate 
>> adaptation, and a host of other wrongs?  Quite possibly.  This much, I 
>> know for sure:  without legitimate elections in a democracy, there can be 
>> no legitimate government.
>> 
>> > 
>> > 
>> > The theory and practice of elections and the specific challenges with
>> > on-line voting is a whole ecosystem of its own with conferences, journals
>> > and an active community of academics, vendors and governments discussing a
>> > fairly broad spectrum from information theory, statistics and cryptography
>> > through to operational and platform security, software quality, public
>> > policy and law.
>> > I am no expert in any of this but I happen to have an academic supervisor
>> > who is. If anybody would like an introduction to that world e.g. as an
>> > alternative to trying to reinvent it at the IETF, I'd be happy to make one.
>> > 
>> > 
>> > Joe
>> > 
>> >
>> 
> 
> 
> -- 
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www..cdt.org]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: [e-mail], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>