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

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

[Michał Górny]

Hi,

Please review the following pre-GLEP.

---
GLEP: 9999
Title: Secrecy-respecting voting mechanism for Gentoo projects
Author: Michał Górny <mgorny@gentoo.org>
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
---

Abstract
========

A new voting system is devised with the aim of providing a single voting
system for all Gentoo elections and votes.  Automation is used to
eliminate the human bottleneck in processing the elections.  Votes are
submitted via random identifers, and the identifiers are sent to voters
via encrypted e-mail to protect the vote secrecy.  E-mail is used to
enable non-developer voters to participate.


Motivation
==========

The votify/countify tooling used to run Gentoo elections dates back
to 2005.  While it still serves it purpose, it has grown antiquated
and is facing a few problems that are discouraging the developers from
using it.  These are:

The problems with the current tooling include:

1. The elections require a lot of manual setup and attention.  This is
   causing noticeable delays and can raise doubts about the validity
   of elections.  For example, voters can still submit or modify votes
   after the deadline until the infra official collects them.

2. The vote secrecy is not respected properly.  While the voting is
   ongoing, the votes are stored in voters' home directories.  Any
   person with superuser access to dev.gentoo.org is capable of reading
   the votes.  Furthermore, there has been a case of votes being
   accidentally disclosed to the mailing list by election officials.

3. Including non-developers as voters is cumbersome and potentially
   violates the vote secrecy.  In the past, it has been either done by
   creating temporary accounts on dev.gentoo.org, or requiring the votes
   to be sent openly via mail and therefore known to the election
   officials.

At this point, votify is  practically used only for the Council
and Trustee elections.  The late attempts of using it for the Base
System and Security project elections have resulted in a lot of
frustration from the developers participating.  The vast majority of
project elections are currently run using third-party services or plain
mail votes.

The goal of this GLEP is to propose a new voting system that meets
the expectations of developers better, and can be easily used to run
elections and referenda by Gentoo developers and projects.


Specification
=============

Requirements for the election system
------------------------------------

The new election system should meet the following requirements:

1. Gentoo developers should be able to start a new election/referendum
   without requesting manual attention of any other individuals.

2. The election system should cover the nomination phase if it is
   applicable, providing the necessary automation to assemble the final
   candidate list.

3. All deadlines should be enforced automatically, and results should
   be published automatically as well.  In particular, it must not be
   possible to modify votes after the final deadline.

4. The secrecy of the votes must be protected to the best of ability.
   This includes both associating a particular vote with a voter,
   as well as determining whether a voter in question has cast a vote.

5. The system should make it easy for non-developers to cast a vote
   on the same terms as developers.


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.

   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.

5. When the voting phase ends, the system publishes the results
   and the master ballot.


Rationale
=========

In the proposed system, the whole election process is automated from
the point of creating the election, through nominations and voting
phases, to publishing the results.  Any developer can easily start
an election without hitting a manpower bottleneck.  This should make it
possible to use the new election system both for major elections such
as the Council elections, and small in-project elections and votes.

The elections/votes can be either based on predefined candidate/option
list, or run a semi-automated nomination phase, to account for various
kinds of elections.

The system is largely based on mail, making it possible to easily
include voters who are not developers.  The most important mails are
PGP-encrypted to provide the necessary authentication for voters
and protect their secrecy.

This GLEP does not enforce a specific UI to the voting system.
An example solution would be to provide a simple web-based UI to handle
nominations and cast votes, using URLs with random identifiers sent via
mail.  Such a system would make it easy for non-developers
to participate.  Creating and managing elections could be done locally
using scripts on dev.gentoo.org.

As long as the underlying tooling is not tampered with, the system
protects the vote secrecy through use of random identifiers.
The association between a random identifiers and a voter name is
preserved only for the short time needed to encrypt the identifier
and send it via mail.  Afterwards, the association is discarded.

After the election concludes, the master ballot is published
and the voters can both verify the election results, and confirm that
their vote has been included in it.

The system does not provide the ability to establish whether
a particular voter has cast a vote or not by design.  This makes it
unsuitable for Trustee elections.


Backwards Compatibility
=======================

The new system can replace the use of votify script, with the exception
of Trustee elections that require the ability to determine who have
voted.  However, there is no reason not to deploy it alongside the old
one.


Reference Implementation
========================

Not complete.


Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike
3.0
Unported License. To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/3.0/.


-- 
Best regards,
Michał Górny

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

[Michael Orlitzky]

On Sat, 2021-08-28 at 12:30 +0200, Michał Górny wrote:
> Hi,
> 
> Please review the following pre-GLEP.
> 

I don't see the word "blockchain" anywhere? AFAIK it is required for
all new voting protocols.



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

Maybe it goes without saying, but anyone with root on the system can
obtain that mapping if he or she really wants to.

It's also important that the identifiers not just be random, but
randomly chosen from a population so large that they are impossible to
guess or brute-force. And we should keep in mind that the identifiers
themselves (but not the mapping) will always be available to someone.


> 
> 5. When the voting phase ends, the system publishes the results
>    and the master ballot.
> 

I can think of a few problematic scenarios:

  * An infra member takes the identifier of someone who doesn't vote, 
    goes to the library, uses seven proxies, and votes for himself.
    Catching this requires a person who did not vote to verify the 
    absence of his identifier on the master ballot, and to reveal that
    he did not vote.

  * Same as above, but the stolen identifier belongs to someone who
    _does_ try to vote. Do we reject his vote? Count both of them?
    Sorting this out would probably require the legitimate voter to 
    reveal information about his vote; at the very least, that he did
    in fact vote.

  * The same person votes more than once. Can we distinguish this from
    the case above?

  * Anyone with access to the votes can just change them. This can be
    caught, but only if the voters verify the master ballot and are 
    willing to speak up and say e.g. "I didn't vote for mgorny!"


None of these are fatal flaws, since votify is even easier to hack. I'm
only pointing them out because I think it's best to have the weaknesses
out in the open.

There is a lot of research being done on anonymous, verifiable (etc.)
voting protocols, but it's hard to tell which ones are junk. The math
literature often overlooks the implementation details, and that's
usually where things go wrong. On the other hand, some implementation
details can be ruled out-of-scope. It's hard to blame the voting system
if the government decides to change the results and What Are You Gonna
Do About It? (Some faith in infra is necessary.)

My point is: in the future it may be worthwhile to document all of the
requirements that we have for a voting system and just ask an expert
for some recommendations that satisfy our criteria. But in the
meantime, this sounds like an easy improvement to the process.

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

[Rich Freeman]

On Sat, Aug 28, 2021 at 6:30 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> 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 happens if an eligible voter reports they didn't get the email
(most likely because email is horribly broken, but it could also be
nefarious)?

I suppose one solution would be to save the encrypted emails before
they are sent.  Then if one is missing it could be retrieved by an
admin/etc and resent.  Since the contents of the email are encrypted
the only info divulged is that somebody was an eligible voter in the
election, which is generally semi-public record around here.  This
avoids creating additional vote identifiers and eliminates any need to
question the validity of the complaint.

-- 
Rich

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

[Aaron Bauman]

On Sat, Aug 28, 2021 at 12:30:15PM +0200, Michał Górny wrote:
> Hi,
> 
> Please review the following pre-GLEP.
> 
> ---
> GLEP: 9999
> Title: Secrecy-respecting voting mechanism for Gentoo projects
> Author: Michał Górny <mgorny@gentoo.org>
> 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
> ---
> 
> Abstract
> ========
> 
> A new voting system is devised with the aim of providing a single voting
> system for all Gentoo elections and votes.  Automation is used to
> eliminate the human bottleneck in processing the elections.  Votes are
> submitted via random identifers, and the identifiers are sent to voters
> via encrypted e-mail to protect the vote secrecy.  E-mail is used to
> enable non-developer voters to participate.
> 
> 
> Motivation
> ==========
> 
> The votify/countify tooling used to run Gentoo elections dates back
> to 2005.  While it still serves it purpose, it has grown antiquated
> and is facing a few problems that are discouraging the developers from
> using it.  These are:
> 
> The problems with the current tooling include:
> 
> 1. The elections require a lot of manual setup and attention.  This is
>    causing noticeable delays and can raise doubts about the validity
>    of elections.  For example, voters can still submit or modify votes
>    after the deadline until the infra official collects them.
>

Given what we have seen in the security election this year, what
determines *who* can start an election? Maybe some clarity in GLEP 39?

> At this point, votify is  practically used only for the Council
> and Trustee elections.  The late attempts of using it for the Base
> System and Security project elections have resulted in a lot of
> frustration from the developers participating.  The vast majority of
> project elections are currently run using third-party services or plain
> mail votes.
>

I am not aware of anyone from the security team having issues with
this... would you please expound on the issues of use?

-Aaron

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

[Rich Freeman]

On Sat, Aug 28, 2021 at 3:01 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> Given what we have seen in the security election this year, what
> determines *who* can start an election? Maybe some clarity in GLEP 39?
>

IMO if there is really a dispute over something like this for a
project election there are some serious issues.

However, if we MUST have rules I'd suggest that it is the
responsibility of the project lead to call for the next project lead
election.  If there is no lead or if the lead has failed to do so in
the last 12 months then anybody should be able to do so.  Obviously it
is best to just nudge the lead or work via consensus.

IMO, formal ballots/etc for project leads is also overkill.  I get the
value for Council/Trustees, but I'm not sure it really adds value for
regular projects.

-- 
Rich

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

[Michał Górny]

On Sat, 2021-08-28 at 15:01 -0400, Aaron Bauman wrote:
> On Sat, Aug 28, 2021 at 12:30:15PM +0200, Michał Górny wrote:
> > Hi,
> > 
> > Please review the following pre-GLEP.
> > 
> > ---
> > GLEP: 9999
> > Title: Secrecy-respecting voting mechanism for Gentoo projects
> > Author: Michał Górny <mgorny@gentoo.org>
> > 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
> > ---
> > 
> > Abstract
> > ========
> > 
> > A new voting system is devised with the aim of providing a single voting
> > system for all Gentoo elections and votes.  Automation is used to
> > eliminate the human bottleneck in processing the elections.  Votes are
> > submitted via random identifers, and the identifiers are sent to voters
> > via encrypted e-mail to protect the vote secrecy.  E-mail is used to
> > enable non-developer voters to participate.
> > 
> > 
> > Motivation
> > ==========
> > 
> > The votify/countify tooling used to run Gentoo elections dates back
> > to 2005.  While it still serves it purpose, it has grown antiquated
> > and is facing a few problems that are discouraging the developers from
> > using it.  These are:
> > 
> > The problems with the current tooling include:
> > 
> > 1. The elections require a lot of manual setup and attention.  This is
> >    causing noticeable delays and can raise doubts about the validity
> >    of elections.  For example, voters can still submit or modify votes
> >    after the deadline until the infra official collects them.
> > 
> 
> Given what we have seen in the security election this year, what
> determines *who* can start an election? Maybe some clarity in GLEP 39?

This is outside the scope of this GLEP.  It's about providing a tool,
not telling how projects select leads.  That's really in scope of GLEP
39 indeed.

> > At this point, votify is  practically used only for the Council
> > and Trustee elections.  The late attempts of using it for the Base
> > System and Security project elections have resulted in a lot of
> > frustration from the developers participating.  The vast majority of
> > project elections are currently run using third-party services or plain
> > mail votes.
> > 
> 
> I am not aware of anyone from the security team having issues with
> this... would you please expound on the issues of use?
> 

The complaints I've seen were primarily because of how long it took for
Elections team to publish results.  I suppose it was in comparison with
Helios where the results are immediately available.

-- 
Best regards,
Michał Górny

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

[Alec Warner]

On Sat, Aug 28, 2021 at 3:30 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> Hi,
>
> Please review the following pre-GLEP.
>
> ---
> GLEP: 9999
> Title: Secrecy-respecting voting mechanism for Gentoo projects
> Author: Michał Górny <mgorny@gentoo.org>
> 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
> ---
>
> Abstract
> ========
>
> A new voting system is devised with the aim of providing a single voting
> system for all Gentoo elections and votes.  Automation is used to
> eliminate the human bottleneck in processing the elections.  Votes are
> submitted via random identifers, and the identifiers are sent to voters
> via encrypted e-mail to protect the vote secrecy.  E-mail is used to
> enable non-developer voters to participate.
>
>
> Motivation
> ==========
>
> The votify/countify tooling used to run Gentoo elections dates back
> to 2005.  While it still serves it purpose, it has grown antiquated
> and is facing a few problems that are discouraging the developers from
> using it.  These are:
>
> The problems with the current tooling include:
>
> 1. The elections require a lot of manual setup and attention.  This is
>    causing noticeable delays and can raise doubts about the validity
>    of elections.  For example, voters can still submit or modify votes
>    after the deadline until the infra official collects them.
>
> 2. The vote secrecy is not respected properly.  While the voting is
>    ongoing, the votes are stored in voters' home directories.  Any
>    person with superuser access to dev.gentoo.org is capable of reading
>    the votes.  Furthermore, there has been a case of votes being
>    accidentally disclosed to the mailing list by election officials.

Why do you want secret elections?

>
> 3. Including non-developers as voters is cumbersome and potentially
>    violates the vote secrecy.  In the past, it has been either done by
>    creating temporary accounts on dev.gentoo.org, or requiring the votes
>    to be sent openly via mail and therefore known to the election
>    officials.
>
> At this point, votify is  practically used only for the Council
> and Trustee elections.  The late attempts of using it for the Base
> System and Security project elections have resulted in a lot of
> frustration from the developers participating.  The vast majority of
> project elections are currently run using third-party services or plain
> mail votes.

I'm not sure disclosing "frustration" is sufficient. If there was
frustration (and FWIW I believe there was) it would be great to get
some detail on the list.

>
> The goal of this GLEP is to propose a new voting system that meets
> the expectations of developers better, and can be easily used to run
> elections and referenda by Gentoo developers and projects.
>
>
> Specification
> =============
>
> Requirements for the election system
> ------------------------------------
>
> The new election system should meet the following requirements:
>
> 1. Gentoo developers should be able to start a new election/referendum
>    without requesting manual attention of any other individuals.
>
> 2. The election system should cover the nomination phase if it is
>    applicable, providing the necessary automation to assemble the final
>    candidate list.
>
> 3. All deadlines should be enforced automatically, and results should
>    be published automatically as well.  In particular, it must not be
>    possible to modify votes after the final deadline.
>
> 4. The secrecy of the votes must be protected to the best of ability.
>    This includes both associating a particular vote with a voter,
>    as well as determining whether a voter in question has cast a vote.
>
> 5. The system should make it easy for non-developers to cast a vote
>    on the same terms as developers.

This seems like a fairly generic problem; are we not sure that a
solution already exists?

>
>
> 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.
>
>    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.
>
> 5. When the voting phase ends, the system publishes the results
>    and the master ballot.
>
>
> Rationale
> =========
>
> In the proposed system, the whole election process is automated from
> the point of creating the election, through nominations and voting
> phases, to publishing the results.  Any developer can easily start
> an election without hitting a manpower bottleneck.  This should make it
> possible to use the new election system both for major elections such
> as the Council elections, and small in-project elections and votes.
>
> The elections/votes can be either based on predefined candidate/option
> list, or run a semi-automated nomination phase, to account for various
> kinds of elections.
>
> The system is largely based on mail, making it possible to easily
> include voters who are not developers.  The most important mails are
> PGP-encrypted to provide the necessary authentication for voters
> and protect their secrecy.
>
> This GLEP does not enforce a specific UI to the voting system.
> An example solution would be to provide a simple web-based UI to handle
> nominations and cast votes, using URLs with random identifiers sent via
> mail.  Such a system would make it easy for non-developers
> to participate.  Creating and managing elections could be done locally
> using scripts on dev.gentoo.org.
>
> As long as the underlying tooling is not tampered with, the system
> protects the vote secrecy through use of random identifiers.
> The association between a random identifiers and a voter name is
> preserved only for the short time needed to encrypt the identifier
> and send it via mail.  Afterwards, the association is discarded.
>
> After the election concludes, the master ballot is published
> and the voters can both verify the election results, and confirm that
> their vote has been included in it.
>
> The system does not provide the ability to establish whether
> a particular voter has cast a vote or not by design.  This makes it
> unsuitable for Trustee elections.
>
>
> Backwards Compatibility
> =======================
>
> The new system can replace the use of votify script, with the exception
> of Trustee elections that require the ability to determine who have
> voted.  However, there is no reason not to deploy it alongside the old
> one.

I'm currently a trustee; and I do not necessarily desire a secret
election for board members; so I'm fine with not using this proposal
for that.

>
>
> Reference Implementation
> ========================
>
> Not complete.
>
>
> Copyright
> =========
> This work is licensed under the Creative Commons Attribution-ShareAlike
> 3.0
> Unported License. To view a copy of this license, visit
> https://creativecommons.org/licenses/by-sa/3.0/.
>
>
> --
> Best regards,
> Michał Górny
>
>
>

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 7414 bytes --]

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@gentoo.org>
> 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@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

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

[Michał Górny]

On Mon, 2021-08-30 at 05:23 +0000, Robin H. Johnson wrote:
> 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@gentoo.org>
> > 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.

Was there actually more than one?  I didn't link it (or search for it)
because it's literally the same proposal, just in GLEP form.

Unless you mean the "community vote verification" which I considered to
be out of the scope.  However, it's going to work the same with this
voting model.

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

I'm sorry but you need to spell this out slower because everything's
just encrypted and I can't decrypt 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.
> 

Nobody's talking about "return mail".  In fact, the rationale section
suggests votes are submitted via HTTPS.  This way in the worst case
Infra can grab IP of the voter but again, they would also have to tamper
with the receiving script to get the vote along with it.

I suppose we could have people submit votes encrypted to the election
officials.  Then I think this will eliminate the problem because Infra
will have access to the IP addresses of voters but not votes,
and election officials will only receive the final ballot.

-- 
Best regards,
Michał Górny