Opened 6 years ago

Last modified 19 months ago

#7148 new defect

Even better parameter voting protocol

Reported by: nickm Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-dirauth security
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Our current parameter voting protocol is backwards in how many voters need to exist for a parameter before we can vote for it. Right now we accept the parameter into the consensus if it has a majority of all authorities, or at least 3 authorities. But that fails when most authorities are abstaining: 3 rogue authorities could force the value of an unset parameter to whatever they want.

A stopgap solution (for which roger is writing a ticket) is for all authorities to vote on all parameters, and to have most/all authorities begin voting on any new parameter before we release software that looks for it.

But surely we can do better than that.

We need to write a little proposal for this before the little-proposal deadline to implement it in 0.2.4.

Child Tickets

Change History (7)

comment:1 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:3 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:4 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:5 Changed 19 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 19 months ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:7 Changed 19 months ago by nickm

Keywords: security added
Severity: Normal
Note: See TracTickets for help on using tickets.