Re: Voting Security (was: The Next Genaration)

Joseph Lorenzo Hall <joe@cdt.org> Sat, 14 September 2019 17:20 UTC

Return-Path: <jhall@cdt.org>
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 97B6812006D for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2019 10:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
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 BzQQE2Om0gEy for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2019 10:20:12 -0700 (PDT)
Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1522F12001E for <ietf@ietf.org>; Sat, 14 Sep 2019 10:20:12 -0700 (PDT)
Received: by mail-io1-xd41.google.com with SMTP id r26so69453742ioh.8 for <ietf@ietf.org>; Sat, 14 Sep 2019 10:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iki1Z9A5GcGhIT5kc2FLZNmGSaPYV4ISDMWEMf2amuk=; b=okcMU791uiMHs51iJVQQJ2FSulJ3vk5cXAa35CtEbsHm4/8C3Rl/sUfY22JK/7PRzk rVcOOVBYBroJD/UboGHW4HzuqXLa64AYC6vs4xODpKzPsB9+s7nl5TLk4nIiMfhoDwu+ FzUqnUdJLBtWmA7PpwKv0Zp7gdXrF+chTk4N0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iki1Z9A5GcGhIT5kc2FLZNmGSaPYV4ISDMWEMf2amuk=; b=eupZ6rtv+Vp2u4Rnyjaiw04iqPRPDb1x2neFbK2jdlPph6DDJ1dJUxiXH/8YM2/iRL hWcIe2Dd9rEiObfQECrW2kR+iGfoNoy/NcUpGbn+TW513VP5Hpo3tH+Qu26uhmYlQDAL 0e5Ebz7sdzE55MV3OG1e3EDJlqzczkdVT9RH9DPHljNtW+ePn6jmxaSrSdiuTidIuuVI mpiG626XE3ccFTw6qwasqRnht1dsIFEfbGeiO4VLMlaVwz5rqsCirWu4NLPtdU7z2Kf8 /qizVeXrXcgBlMIRxuGGBJ/dXnJdcrS7vLvVd8j2PwW6l94VUOZZ3hVlV/vEIxJayXga fyzg==
X-Gm-Message-State: APjAAAUlb/cjLf41/h3Lo+GW6/cc5IZwzz45Bw4ooHqU9ofzz848BoSi AX5269ihSkFhxAZCyOMpdYYYvjkCe09PM+d7GVoRsA==
X-Google-Smtp-Source: APXvYqwDSys/oaaGWKSt3bFHLRxjc3ZawjEqlc/J6WCbda+mrHCB3j6lj1KLa3eYDhg9YXbG4pDGq/rjbKN2U6DOiMY=
X-Received: by 2002:a6b:8d06:: with SMTP id p6mr6868811iod.219.1568481611076; Sat, 14 Sep 2019 10:20:11 -0700 (PDT)
MIME-Version: 1.0
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> <alpine.DEB.2.21.1909140303190.32554@sleekfreak.ath.cx>
In-Reply-To: <alpine.DEB.2.21.1909140303190.32554@sleekfreak.ath.cx>
From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Sat, 14 Sep 2019 13:19:59 -0400
Message-ID: <CABtrr-UQXtjUmEMHxr_eV=jJ-h8YtwtEY60aLe9u_Bb+zAiJdg@mail.gmail.com>
Subject: Re: Voting Security (was: The Next Genaration)
To: shogunx@sleekfreak.ath.cx
Cc: Joe Abley <jabley@hopcount.ca>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000043f0040592869585"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/T1WSf9WKZTAhBWYhfHE_CrsQBTk>
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 17:20:15 -0000

(I've had this argument dozens maybe hundreds of times, not going to do
that here.)

On Sat, Sep 14, 2019 at 3:28 AM <shogunx@sleekfreak.ath.cx> 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: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871