Re: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects

[Robin H. Johnson]

On Sat, Aug 28, 2021 at 12:30:15PM +0200, Michał Górny wrote:
> Please review the following pre-GLEP.
Please don't take the rest of my mail as a dismissal, but rather as
considering how to protect Gentoo's voting system from any attack that I
feel I might even remotely have the system privilege level to conduct.

I absolutely do want improvements to Gentoo's voting process, like I
said last year in mentioning mail-in ballot systems.

>
> ---
> GLEP: 9999
> Title: Secrecy-respecting voting mechanism for Gentoo projects
> Author: Michał Górny <mgorny@g.o>
> Type: Standards Track
> Status: Draft
> Version: 1
> Created: 2021-08-27
> Last-Modified: 2021-08-27
> Post-History: 2021-08-27
> Content-Type: text/x-rst
Can you please reference all of your earlier proposals about changing
the voting system, because this isn't the first time you've suggested
it, and there have been prior suggestions by others as well.

...
> The election process
> --------------------
>
> Each election/referendum consists of the following steps:
>
> 1. A developer creates a new election/referendum.  During this step,
>    the developer specifies whether the boundary dates for each election
>    phase, the voter list and the (potential) candidates.
>
> 2. If the nomination phase is applicable, the system accepts nominations
>    from the voters.  Each nominated candidate is mailed about
>    the nomination, and given the explicit choice of accepting
>    or declining it.  If the nomination is accepted, the candidate may
>    also upload a manifesto.
>
> 3. When the voting phase beings, the system creates random identifiers
>    for all voters.  Each identifier is encrypted using voter's PGP key
>    and sent via email to the voter.  The voter-identifier mapping is
>    discarded immediately to reduce the risk of it leaking.
What if each voter generates their OWN identifier (using tooling), and
includes it in an encrypted ballot, such that it later winds up in the
master ballot, where they can verify it...

>    If the nomination phase was enabled, the system also creates
>    the final candidate list from nominees who accepted their nomination.
>
> 4. Voters submit their votes using their random identifiers.
Can you expand on this step more?

If I send a mail to the gentoo.org email system, it must by definition
contain somewhere:
- my email address as the sender
- my identifier

If there's no encryption on the return mail, both details are
potentially available to anybody in infra, which is one of the parties
we want to block.

Obviously then, some encryption is required, but where and how?

I think we need to decide on which requirements/concerns matter more:
- tamper-proof/evident
- secrecy: of ballot content (e.g. who did X vote for?)
- secrecy: of vote existence (e.g. did X vote)
- ballot stuffing protection
- identity fraud
- pay-for-specific-vote (bribes to vote for Mallory)

And then consider how to handle those. These are not the only
requirements that might exist in a voting system, but some of the
partial list that came to mind while writing this email, based on my
knowledge and background.

There are two sets of "trusted" parties:
- election officials: who could collude to tamper with a master ballot
  [1]
- infra: who have access to email, LDAP, root on systems. As a statement
  of fact today data about the envelope from/to/msg-id/subject/date and
  some extra headers are always logged.
  Any mail in the queue could theoretically be examined for it's body as
  well.

[1] How can election officials tamper with votify today? If the election
officials were to collude, they can create inject additional ballots
between the countify --collect and countify --rank phase.

Some of these requirements can be see as in opposition to each other:
how do you prevent ballot stuffing & identity fraud while also knowing
who did or didn't vote.

Last year, I recall having some discussions about how real-world mail-in
ballots are conducted, using nested envelopes, and strict separation of
responsibilities. I will note that not all mail-in systems permit you to
replace your earlier ballot, as a tradeoff in their design.

The one local to me uses this model:
https://elections.bc.ca/docs/VoteByMailInstructions.pdf

- 0: A ballot, with the choices, and possibly identification markings on
  the ballot itself (**, this exists in some systems to detect some
  forms of ballot stuffing, e.g. if serial numbers 1-500 went to
  location X, they shouldn't turn up in location Y, which had numbers
  500-1000).
- A: secrecy sleeve/envelope, to hide what the ballot says [encryption]
- B: certification envelope, that identifies the voter [authentication]
- C: mail envelope, that is addressed to the elections organization, and
  gets a time-coded stamp when it's received (via postmarking, which may
  also disclose the location of the voter).

This system requires two trusted but separate groups of people, (G1, G2):
G1.1. - when each envelope C arrives, verify B against database, notate
        when it arrived. Discard earlier envelope B from the voter.
		Separate any envelope B for where it cannot be verified against
		the database.
G1.2. - at the counting time, open the latest envelope C for each
        eligible voter, and produce a pile of SEALED secrecy sleeves/envelopes.
G2.1. - Gets the sleeves with ballots inside them, and tallies ballots to produce the outcome.

I think we can implement at least part of this with infra & election
officials as trusted-AND-separate groups.

The following isn't a fully fleshed out plan, and we can probably look
at existing proposals and find something that's close enough to our
requirements.

Infra will end up knowing who voted, because they have access to the
email logs. So any system we design needs to make sure that Infra cannot
inject a vote of somebody else who didn't vote. I think the most obvious
way to do this is something like the certification envelope, which could
take the form of a GPG-signed message (but the message content must be
separately encrypted)

The system would have to take the latest signed message for each voter,
and export ONLY the encrypted content (without decrypting it). This also
produces a list of who voted as an additional output (but it should be
impossible to map a given name to a given ballot).

The ballots themselves need to be separately encrypted TO the election
officials for a given election.

What should be inside a ballot?
- Identifier, generated by the voter's system, so that the voter can
  confirm that THEIR ballot was included, and was not tampered with.
  The voter should NOT choose an identifier that accidentally discloses
  their identity to any other part.
- The choices of the voter


What are the holes in this system?

If a voter discloses their ballot identifier to a third party BEFORE the
master ballot is published, then the third party can be sure who the
voter picked. This is under the pay-for-specific vote concern.

This mail to be continued.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136