Re: Voting Security (was: The Next Genaration)

shogunx@sleekfreak.ath.cx Sat, 14 September 2019 07:28 UTC

Return-Path: <shogunx@sleekfreak.ath.cx>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767E4120090 for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2019 00:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNrY-9SoCmvY for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2019 00:28:27 -0700 (PDT)
Received: from sleekfreak.ath.cx (sleekfreak.ath.cx [IPv6:2602:fdf2:bee:feed::1999]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121E3120088 for <ietf@ietf.org>; Sat, 14 Sep 2019 00:28:27 -0700 (PDT)
Received: from shogunx (helo=localhost) by sleekfreak.ath.cx with local-esmtp (Exim 4.92) (envelope-from <shogunx@sleekfreak.ath.cx>) id 1i92U5-0003bX-3A; Sat, 14 Sep 2019 03:28:41 -0400
Date: Sat, 14 Sep 2019 03:28:41 -0400
From: shogunx@sleekfreak.ath.cx
To: Joe Abley <jabley@hopcount.ca>
cc: Eric Rescorla <ekr@rtfm.com>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Voting Security (was: The Next Genaration)
In-Reply-To: <B7BC79DD-617E-4FFA-A414-76C5C0287C00@hopcount.ca>
Message-ID: <alpine.DEB.2.21.1909140303190.32554@sleekfreak.ath.cx>
References: <CAChr6Sz3j0iLGsB2bGvfitPzCkiTCJYHfmUF5S-8zPYMt1r+3A@mail.gmail.com> <6.2.5.6.2.20190911094010.0c933fa8@elandnews.com> <20190911194723.GC18811@localhost> <6.2.5.6.2.20190911131143.11401cb8@elandnews.com> <CAMm+Lwi2CDBCDUhMG7Z487G-BYVp4rRJ=YG73Z=M=TkZ=jaAbQ@mail.gmail.com> <alpine.DEB.2.21.1909121135080.32554@sleekfreak.ath.cx> <CABcZeBMp7dzvTGnPTk=q79pf5KYiMd0eepEXiyFw=imPNkSfBg@mail.gmail.com> <B7BC79DD-617E-4FFA-A414-76C5C0287C00@hopcount.ca>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7hrUNpsoAdxaHI4eHn1QXNpQ9og>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 07:28:28 -0000

> 
> 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
> 
>