[prev in list] [next in list] [prev in thread] [next in thread]
List: tor-dev
Subject: [tor-dev] help
From: Juan Berner <89berner () gmail ! com>
Date: 2015-11-20 16:30:32
Message-ID: CAOtGfvYiaSp_RSGf9O51D+Z+QWAXwSQZHKbEXW9fc5AoB3-8Wg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2015-11-20 17:24 GMT+01:00 <tor-dev-request@lists.torproject.org>:
> Send tor-dev mailing list submissions to
> tor-dev@lists.torproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> or, via email, send a message with subject or body 'help' to
> tor-dev-request@lists.torproject.org
>
> You can reach the person managing the list at
> tor-dev-owner@lists.torproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Shared random value calculation edge cases (proposal 250)
> (George Kadianakis)
> 2. Re: Shared random value calculation edge cases (proposal 250)
> (David Goulet)
> 3. Re: Shared random value calculation edge cases (proposal 250)
> (David Goulet)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Nov 2015 16:06:59 +0200
> From: George Kadianakis <desnacked@riseup.net>
> To: s7r <s7r@sky-ip.org>
> Cc: tor-dev@lists.torproject.org
> Subject: Re: [tor-dev] Shared random value calculation edge cases
> (proposal 250)
> Message-ID: <87fv0069z0.fsf@riseup.net>
> Content-Type: text/plain
>
> s7r <s7r@sky-ip.org> writes:
>
> > Hello,
> >
> > <snip>
> >
> > The idea of adding flags in the votes so each dirauth can advertise if
> > it is participating (has an opinion for the <current> SR or not) is
> > great and helps us build more defenses, probably make it easier in the
> > future too if we decide to change anything.
> >
> > What if the consensus for SR calculation would define majority based
> > on dirauths actually participating (and advertising so with a flag in
> > the vote). Also, the participating or not participating flag should be
> > used per vote/consensus and split into:
> >
> > a) we know current SR value for today so we vote it
> > or
> > we know previous SR value and we know for sure if we should follow the
> > disaster protocol or not (in case we are about to vote at 01:00 UTC).
> > so
> > We participate in the vote for <current SR>.
> >
> > b) we are able to participate in this protocol run which will
> > calculate the SR value for next day (after 00:00 UTC) so we send our
> > commits/reveals.
> >
> > This is useful in case we are a dirauth that joined at 00:30 UTC and
> > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC
> > consensus was created, and if not, previous SR value so we can follow
> > the disaster procedure) we will not have an opinion for the <current>
> > SR value at 01:00 UTC, but we can start participating in the protocol
> > run for the next day - send our commit values. Once we decided on a
> > <current> SR value for that day we save it and vote normally next time.
> >
> > So, if we have 5 dirauths running/signing consensus in total, out of
> > which only 4 participate in the shared randomness protocol, the 4
> > participating ones should be able to create a valid consensus
> > themselves with the insurance that the 5th one won't break consensus.
> >
> > One way to do this is: the dirauth which is not participating will
> > take the SR value voted by the majority of the participating dirauths
> > and include that in its consensus and sign. We need at least 3
> > dirauths agreeing on a SR value in order to accept it.
> >
> > Is this crazy? It shouldn't open the door new attacks, since this
> > doesn't allow a single actor to game it, only the majority could game it.
> >
>
> Thanks for the suggestions.
>
> Let me try to suggest a procedure here based on your ideas and some other
> ideas.
>
> [Notation: SRV = shared random value]
>
> The goal here is to minimize the edge cases during SRV calculation and
> disaster
> SRV calculation. The edge cases here appear because there is no clear view
> on
> whether other dirauths know the current or previous SRVs, or whether the
> SRV for
> this period was ever created. The disaster recovery scenario is especially
> annoying here.
>
> Here are some edge cases for example:
>
> * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain
> any
> SR information (maybe because not enough SR-enabled dirauths
> participated at
> that time).
>
> Should the dirauth do the disaster recovery procedure, or just play it
> cool
> and put no SR information on the consensus? If it has to do disaster
> recovery,
> then what previous SRV does it use (the 01:00UTC consensus did not
> contain
> such info)?
>
> This type of edge case is my main concern, since with dirauths upgrading
> and
> going offline at random times, it's likely that we will eventually
> create a
> consensus without SR info in the middle of the protocol run.
>
> * Dirauth boots up at 23:55UTC without having a previous consensus. It is
> supposed to vote and form a 00:00UTC consensus without knowing any
> previous
> SRVs. How does it figure out whether all the other dirauths are also
> bootstrapping, or whether the other dirauths actually know the previous
> SRVs?
>
> Here are some prerequisites for the logic I'm going to suggest. The two
> first
> suggestions are useful in any case, I think:
>
> - First of all, we treat consensuses as trusted, so dirauths MUST learn
> previous/current SRVs they didn't know about from any consensus they
> fetch.
>
> - We are also going to assume that we have some sort of "SR flag" on votes
> to
> denote whether the dirauth participates in the protocol.
>
> - We are introducing another 'status' for shared random values (see
> [SRVOTE]).
>
> Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be
> created, or it did not contain any SRV information, then it sets the
> status of
> "shared-rand-current-value" in its votes to "none".
>
> Now we are going to use the SRV lines in the votes as an indicator on how
> the
> consensus creation should play out.
>
>
> ================================================================================
>
> Here is some logic for the consensus at 00:00UTC:
>
> if majority of votes have disabled the SR flag:
> then don't write anything SR-related to consensus
> exit
>
> If the majority of votes contain the previous SRV value:
> then calculate SRV as detailed in section [SRCALC]
> else:
> then calculate SRV as in [SRCALC] but with previous_SRV set
> to 0
>
> And here is some logic for all the other consensuses (to figure out when
> dirauths should perform the disaster procedure):
>
> if majority of votes have disabled the SR flag:
> then don't write anything SR-related to consensus
> exit
>
> if we know the current SRV:
> then write it on the consensus
> exit
>
> if the majority of votes have the current SRV status as "none" _AND_
> those votes also contain the previous SRV value:
> then do the disaster SRV procedure
> else:
> then don't write anything SR-related to consensus
>
>
> ================================================================================
>
> This _might_ work for fixing a good bunch of edge cases. But is it far too
> complex?
>
> Should we just assume that these things will never happen on the real
> network
> and avoid baking additional complexity? What do you think? :/
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Nov 2015 10:19:07 -0500
> From: David Goulet <dgoulet@ev0ke.net>
> To: tor-dev@lists.torproject.org
> Subject: Re: [tor-dev] Shared random value calculation edge cases
> (proposal 250)
> Message-ID: <20151120151907.GD10269@raoul>
> Content-Type: text/plain; charset="us-ascii"
>
> On 20 Nov (16:06:59), George Kadianakis wrote:
> > s7r <s7r@sky-ip.org> writes:
> >
> > > Hello,
> > >
> > > <snip>
> > >
> > > The idea of adding flags in the votes so each dirauth can advertise if
> > > it is participating (has an opinion for the <current> SR or not) is
> > > great and helps us build more defenses, probably make it easier in the
> > > future too if we decide to change anything.
> > >
> > > What if the consensus for SR calculation would define majority based
> > > on dirauths actually participating (and advertising so with a flag in
> > > the vote). Also, the participating or not participating flag should be
> > > used per vote/consensus and split into:
> > >
> > > a) we know current SR value for today so we vote it
> > > or
> > > we know previous SR value and we know for sure if we should follow the
> > > disaster protocol or not (in case we are about to vote at 01:00 UTC).
> > > so
> > > We participate in the vote for <current SR>.
> > >
> > > b) we are able to participate in this protocol run which will
> > > calculate the SR value for next day (after 00:00 UTC) so we send our
> > > commits/reveals.
> > >
> > > This is useful in case we are a dirauth that joined at 00:30 UTC and
> > > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC
> > > consensus was created, and if not, previous SR value so we can follow
> > > the disaster procedure) we will not have an opinion for the <current>
> > > SR value at 01:00 UTC, but we can start participating in the protocol
> > > run for the next day - send our commit values. Once we decided on a
> > > <current> SR value for that day we save it and vote normally next time.
> > >
> > > So, if we have 5 dirauths running/signing consensus in total, out of
> > > which only 4 participate in the shared randomness protocol, the 4
> > > participating ones should be able to create a valid consensus
> > > themselves with the insurance that the 5th one won't break consensus.
> > >
> > > One way to do this is: the dirauth which is not participating will
> > > take the SR value voted by the majority of the participating dirauths
> > > and include that in its consensus and sign. We need at least 3
> > > dirauths agreeing on a SR value in order to accept it.
> > >
> > > Is this crazy? It shouldn't open the door new attacks, since this
> > > doesn't allow a single actor to game it, only the majority could game
> it.
> > >
> >
> > Thanks for the suggestions.
> >
> > Let me try to suggest a procedure here based on your ideas and some
> other ideas.
> >
> > [Notation: SRV = shared random value]
> >
> > The goal here is to minimize the edge cases during SRV calculation and
> disaster
> > SRV calculation. The edge cases here appear because there is no clear
> view on
> > whether other dirauths know the current or previous SRVs, or whether the
> SRV for
> > this period was ever created. The disaster recovery scenario is
> especially
> > annoying here.
> >
> > Here are some edge cases for example:
> >
> > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not
> contain any
> > SR information (maybe because not enough SR-enabled dirauths
> participated at
> > that time).
> >
> > Should the dirauth do the disaster recovery procedure, or just play it
> cool
> > and put no SR information on the consensus? If it has to do disaster
> recovery,
> > then what previous SRV does it use (the 01:00UTC consensus did not
> contain
> > such info)?
> >
> > This type of edge case is my main concern, since with dirauths
> upgrading and
> > going offline at random times, it's likely that we will eventually
> create a
> > consensus without SR info in the middle of the protocol run.
> >
> > * Dirauth boots up at 23:55UTC without having a previous consensus. It is
> > supposed to vote and form a 00:00UTC consensus without knowing any
> previous
> > SRVs. How does it figure out whether all the other dirauths are also
> > bootstrapping, or whether the other dirauths actually know the
> previous SRVs?
> >
> > Here are some prerequisites for the logic I'm going to suggest. The two
> first
> > suggestions are useful in any case, I think:
> >
> > - First of all, we treat consensuses as trusted, so dirauths MUST learn
> > previous/current SRVs they didn't know about from any consensus they
> fetch.
>
> Yes ++.
>
> A dirauth booting up should always try to learn the current and previous
> SRV from the latest consensus (< 24h) and update the disk state
> accordingly _even_ if the disk state has SRV values in there. We should
> trust the consensus voted by majority before our disk state imo.
>
> >
> > - We are also going to assume that we have some sort of "SR flag" on
> votes to
> > denote whether the dirauth participates in the protocol.
>
> The requirements for having that flag "on" or "off" eludes me a bit. I
> assume that this SR flag is "on" when a dirauth thinks its able to
> compute a valid SRV that is I have enough commits. We can't make "having
> the previous SRV" a requirement else we will never bootstrap properly
> ever since in the first runs, previous SRV is alway 0.
>
> >
> > - We are introducing another 'status' for shared random values (see
> [SRVOTE]).
> >
> > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be
> > created, or it did not contain any SRV information, then it sets the
> status of
> > "shared-rand-current-value" in its votes to "none".
>
> Hrm... I'm wondering here if "none" status is instead the same of having
> the dirauth putting the disaster value in the vote?
>
> I would argue that a dirauth should _always_ try to compute a SR value
> at any time (even when booting). Between having no line because we
> couldn't compute due to lack of commits or a line that is the disaster,
> I think the former simplifies things that is "We always have a SRV value
> at 00:00 from a dirauth".
>
> Here is what I propose:
>
> 1) Like you said, we always try to learn SRV values from previous
> consensus. If we can't get one from a consensus or our state, compute
> disaster at 00:00.
>
> 2) We do _not_ use a SR flag for vote, a dirauth always tries to compute
> a current SRV value at 00:00. If it's 13:00, it simply doesn't put
> anything in the vote since no SRV data.
>
> The big issue I see here is when a dirauth does _not_ have the previous
> SRV. Without it, both disaster and current SRV computation will end up
> not matching the majority. So let's explore this binary state:
>
> - I have the previous SRV (either I can get it from my state or
> consensus).
>
> This seems a non issue, dirauth will use it, carry it in the vote and
> compute the current SRV if enough commits have been seen. At 00:00, if
> majority wasn't reached for the current SRV value, we have a consensus
> without it which is a valid use case but we at least have the previous
> one in the consensus flagged as non-fresh so it can be used for
> disaster or SRV computation at the next protocol run.
>
> - I don't have a previous SRV (couldn't get it in the latest consensus
> and I have _no_ disk state).
>
> For instance, if this happens at 23:30, a dirauth won't have the
> chance to participate in the SR protocol because it didn't see any
> commits to compute SRV value thus disaster mode engage.
>
> If that dirauth was the 5th one out of 9 (meaning the majority
> breaker), we end up with no SRV values at all at 00:00 (not even the
> previous SRV since only 4/9 had it). So a new protocol run starts,
> we'll end up with a valid current SRV in 24 hours and both values in
> 48 hours. Essentially, we end up back in bootstrap mode.
>
> IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values
> that aren't in the 00:00 consensus.
>
> Question is, how big of a deal it is to have this issue where if we
> don't reach majority because a dirauth rebooted and for some magical
> reason didn't get the latest consensus to at least get the previous
> SRV, we return in bootstrap?
>
> Cheers!
> David
>
> >
> > Now we are going to use the SRV lines in the votes as an indicator on
> how the
> > consensus creation should play out.
> >
> >
> ================================================================================
> >
> > Here is some logic for the consensus at 00:00UTC:
> >
> > if majority of votes have disabled the SR flag:
> > then don't write anything SR-related to consensus
> > exit
> >
> > If the majority of votes contain the previous SRV value:
> > then calculate SRV as detailed in section [SRCALC]
> > else:
> > then calculate SRV as in [SRCALC] but with previous_SRV
> set to 0
> >
> > And here is some logic for all the other consensuses (to figure out when
> > dirauths should perform the disaster procedure):
> >
> > if majority of votes have disabled the SR flag:
> > then don't write anything SR-related to consensus
> > exit
> >
> > if we know the current SRV:
> > then write it on the consensus
> > exit
> >
> > if the majority of votes have the current SRV status as "none" _AND_
> > those votes also contain the previous SRV value:
> > then do the disaster SRV procedure
> > else:
> > then don't write anything SR-related to consensus
> >
> >
> ================================================================================
> >
> > This _might_ work for fixing a good bunch of edge cases. But is it far
> too complex?
> >
> > Should we just assume that these things will never happen on the real
> network
> > and avoid baking additional complexity? What do you think? :/
> >
> >
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 603 bytes
> Desc: Digital signature
> URL: <
> http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/c02f52ca/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Nov 2015 11:24:24 -0500
> From: David Goulet <dgoulet@ev0ke.net>
> To: tor-dev@lists.torproject.org
> Subject: Re: [tor-dev] Shared random value calculation edge cases
> (proposal 250)
> Message-ID: <20151120162424.GE10269@raoul>
> Content-Type: text/plain; charset="us-ascii"
>
> On 20 Nov (10:19:07), David Goulet wrote:
> > On 20 Nov (16:06:59), George Kadianakis wrote:
> > > s7r <s7r@sky-ip.org> writes:
> > >
> > > > Hello,
> > > >
> > > > <snip>
> > > >
> > > > The idea of adding flags in the votes so each dirauth can advertise
> if
> > > > it is participating (has an opinion for the <current> SR or not) is
> > > > great and helps us build more defenses, probably make it easier in
> the
> > > > future too if we decide to change anything.
> > > >
> > > > What if the consensus for SR calculation would define majority based
> > > > on dirauths actually participating (and advertising so with a flag in
> > > > the vote). Also, the participating or not participating flag should
> be
> > > > used per vote/consensus and split into:
> > > >
> > > > a) we know current SR value for today so we vote it
> > > > or
> > > > we know previous SR value and we know for sure if we should follow
> the
> > > > disaster protocol or not (in case we are about to vote at 01:00 UTC).
> > > > so
> > > > We participate in the vote for <current SR>.
> > > >
> > > > b) we are able to participate in this protocol run which will
> > > > calculate the SR value for next day (after 00:00 UTC) so we send our
> > > > commits/reveals.
> > > >
> > > > This is useful in case we are a dirauth that joined at 00:30 UTC and
> > > > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC
> > > > consensus was created, and if not, previous SR value so we can follow
> > > > the disaster procedure) we will not have an opinion for the <current>
> > > > SR value at 01:00 UTC, but we can start participating in the protocol
> > > > run for the next day - send our commit values. Once we decided on a
> > > > <current> SR value for that day we save it and vote normally next
> time.
> > > >
> > > > So, if we have 5 dirauths running/signing consensus in total, out of
> > > > which only 4 participate in the shared randomness protocol, the 4
> > > > participating ones should be able to create a valid consensus
> > > > themselves with the insurance that the 5th one won't break consensus.
> > > >
> > > > One way to do this is: the dirauth which is not participating will
> > > > take the SR value voted by the majority of the participating dirauths
> > > > and include that in its consensus and sign. We need at least 3
> > > > dirauths agreeing on a SR value in order to accept it.
> > > >
> > > > Is this crazy? It shouldn't open the door new attacks, since this
> > > > doesn't allow a single actor to game it, only the majority could
> game it.
> > > >
> > >
> > > Thanks for the suggestions.
> > >
> > > Let me try to suggest a procedure here based on your ideas and some
> other ideas.
> > >
> > > [Notation: SRV = shared random value]
> > >
> > > The goal here is to minimize the edge cases during SRV calculation and
> disaster
> > > SRV calculation. The edge cases here appear because there is no clear
> view on
> > > whether other dirauths know the current or previous SRVs, or whether
> the SRV for
> > > this period was ever created. The disaster recovery scenario is
> especially
> > > annoying here.
> > >
> > > Here are some edge cases for example:
> > >
> > > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not
> contain any
> > > SR information (maybe because not enough SR-enabled dirauths
> participated at
> > > that time).
> > >
> > > Should the dirauth do the disaster recovery procedure, or just play
> it cool
> > > and put no SR information on the consensus? If it has to do disaster
> recovery,
> > > then what previous SRV does it use (the 01:00UTC consensus did not
> contain
> > > such info)?
> > >
> > > This type of edge case is my main concern, since with dirauths
> upgrading and
> > > going offline at random times, it's likely that we will eventually
> create a
> > > consensus without SR info in the middle of the protocol run.
> > >
> > > * Dirauth boots up at 23:55UTC without having a previous consensus. It
> is
> > > supposed to vote and form a 00:00UTC consensus without knowing any
> previous
> > > SRVs. How does it figure out whether all the other dirauths are also
> > > bootstrapping, or whether the other dirauths actually know the
> previous SRVs?
> > >
> > > Here are some prerequisites for the logic I'm going to suggest. The
> two first
> > > suggestions are useful in any case, I think:
> > >
> > > - First of all, we treat consensuses as trusted, so dirauths MUST learn
> > > previous/current SRVs they didn't know about from any consensus they
> fetch.
> >
> > Yes ++.
> >
> > A dirauth booting up should always try to learn the current and previous
> > SRV from the latest consensus (< 24h) and update the disk state
> > accordingly _even_ if the disk state has SRV values in there. We should
> > trust the consensus voted by majority before our disk state imo.
> >
> > >
> > > - We are also going to assume that we have some sort of "SR flag" on
> votes to
> > > denote whether the dirauth participates in the protocol.
> >
> > The requirements for having that flag "on" or "off" eludes me a bit. I
> > assume that this SR flag is "on" when a dirauth thinks its able to
> > compute a valid SRV that is I have enough commits. We can't make "having
> > the previous SRV" a requirement else we will never bootstrap properly
> > ever since in the first runs, previous SRV is alway 0.
> >
> > >
> > > - We are introducing another 'status' for shared random values (see
> [SRVOTE]).
> > >
> > > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to
> be
> > > created, or it did not contain any SRV information, then it sets the
> status of
> > > "shared-rand-current-value" in its votes to "none".
> >
> > Hrm... I'm wondering here if "none" status is instead the same of having
> > the dirauth putting the disaster value in the vote?
> >
> > I would argue that a dirauth should _always_ try to compute a SR value
> > at any time (even when booting). Between having no line because we
> > couldn't compute due to lack of commits or a line that is the disaster,
> > I think the former simplifies things that is "We always have a SRV value
> > at 00:00 from a dirauth".
> >
> > Here is what I propose:
> >
> > 1) Like you said, we always try to learn SRV values from previous
> > consensus. If we can't get one from a consensus or our state, compute
> > disaster at 00:00.
> >
> > 2) We do _not_ use a SR flag for vote, a dirauth always tries to compute
> > a current SRV value at 00:00. If it's 13:00, it simply doesn't put
> > anything in the vote since no SRV data.
> >
> > The big issue I see here is when a dirauth does _not_ have the previous
> > SRV. Without it, both disaster and current SRV computation will end up
> > not matching the majority. So let's explore this binary state:
> >
> > - I have the previous SRV (either I can get it from my state or
> > consensus).
> >
> > This seems a non issue, dirauth will use it, carry it in the vote and
> > compute the current SRV if enough commits have been seen. At 00:00, if
> > majority wasn't reached for the current SRV value, we have a consensus
> > without it which is a valid use case but we at least have the previous
> > one in the consensus flagged as non-fresh so it can be used for
> > disaster or SRV computation at the next protocol run.
> >
> > - I don't have a previous SRV (couldn't get it in the latest consensus
> > and I have _no_ disk state).
> >
> > For instance, if this happens at 23:30, a dirauth won't have the
> > chance to participate in the SR protocol because it didn't see any
> > commits to compute SRV value thus disaster mode engage.
> >
> > If that dirauth was the 5th one out of 9 (meaning the majority
> > breaker), we end up with no SRV values at all at 00:00 (not even the
> > previous SRV since only 4/9 had it). So a new protocol run starts,
> > we'll end up with a valid current SRV in 24 hours and both values in
> > 48 hours. Essentially, we end up back in bootstrap mode.
> >
> > IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values
> > that aren't in the 00:00 consensus.
> >
> > Question is, how big of a deal it is to have this issue where if we
> > don't reach majority because a dirauth rebooted and for some magical
> > reason didn't get the latest consensus to at least get the previous
> > SRV, we return in bootstrap?
>
> Ok more thoughts on this, asn asked that I make an algorithm so here is
> a try at that:
>
> -- Booting up Conditions --
>
> - A dirauth MUST try to acquire both previous and current SRV from
> the last consensus. If it can't, get it from disk state. If
> nothing is available, none exists for this protocol run.
>
> -- Algorithm --
>
> At 16:00 (arbitrary time which is _not_ the current SRV calculation):
>
> # Voting
> if dirauth has previous SRV:
> put it in vote
> if dirauth has current SRV:
> put it in vote
>
> Output: Consensus is created
>
> # Consensus
> (This goes for both previous and current SRV)
> if SRV in consensus:
> dirauth MUST keep it even if the one they have doesn't match.
> Majority has decided what should be used.
> else:
> dirauth MUST discard the SRV it has.
>
> At 00:00
>
> # Voting
> if current SRV can't be created because lack of commits:
> current SRV == disaster mode (previous SRV or not)
> else:
> compute current SRV (with or without a previous SRV)
>
> (Proceed like the 16:00 period)
>
> # Consensus
> if majority agrees on SR value(s):
> put in consensus
> else:
> No SR value(s) in consensus
>
> Output: consensus is created
>
> (Proceed like the 16:00 period)
>
>
> Side effect of only keeping SRV that are in the consensus. If one voting
> round goes bad for X reason and consensus end up with no SRV, we end up
> in bootstrapping mode that is no previous nor current SRV in the
> consensus which is problematic because for 48 hours, we won't have a
> previous SRV which is the one used by everyone.
>
> I don't see a way to get out of this because consensus is decided from
> the votes deterministically thus if not enough vote for SR values, we'll
> end up with a consensus with none so this is why client/HS have to
> fallback to a disaster value by themselves I think which can NOT be
> based on the previous SRV.
>
> David
>
> >
> > Cheers!
> > David
> >
> > >
> > > Now we are going to use the SRV lines in the votes as an indicator on
> how the
> > > consensus creation should play out.
> > >
> > >
> ================================================================================
> > >
> > > Here is some logic for the consensus at 00:00UTC:
> > >
> > > if majority of votes have disabled the SR flag:
> > > then don't write anything SR-related to consensus
> > > exit
> > >
> > > If the majority of votes contain the previous SRV value:
> > > then calculate SRV as detailed in section [SRCALC]
> > > else:
> > > then calculate SRV as in [SRCALC] but with previous_SRV
> set to 0
> > >
> > > And here is some logic for all the other consensuses (to figure out
> when
> > > dirauths should perform the disaster procedure):
> > >
> > > if majority of votes have disabled the SR flag:
> > > then don't write anything SR-related to consensus
> > > exit
> > >
> > > if we know the current SRV:
> > > then write it on the consensus
> > > exit
> > >
> > > if the majority of votes have the current SRV status as "none"
> _AND_
> > > those votes also contain the previous SRV value:
> > > then do the disaster SRV procedure
> > > else:
> > > then don't write anything SR-related to consensus
> > >
> > >
> ================================================================================
> > >
> > > This _might_ work for fixing a good bunch of edge cases. But is it far
> too complex?
> > >
> > > Should we just assume that these things will never happen on the real
> network
> > > and avoid baking additional complexity? What do you think? :/
> > >
> > >
> > > _______________________________________________
> > > tor-dev mailing list
> > > tor-dev@lists.torproject.org
> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 603 bytes
> Desc: Digital signature
> URL: <
> http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/68e8133d/attachment.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> ------------------------------
>
> End of tor-dev Digest, Vol 58, Issue 39
> ***************************************
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-11-20 \
17:24 GMT+01:00 <span dir="ltr"><<a \
href="mailto:tor-dev-request@lists.torproject.org" \
target="_blank">tor-dev-request@lists.torproject.org</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Send tor-dev mailing list submissions to<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" \
rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:tor-dev-request@lists.torproject.org">tor-dev-request@lists.torproject.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:tor-dev-owner@lists.torproject.org">tor-dev-owner@lists.torproject.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of tor-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Shared random value calculation edge cases (proposal 250)<br>
(George Kadianakis)<br>
2. Re: Shared random value calculation edge cases (proposal 250)<br>
(David Goulet)<br>
3. Re: Shared random value calculation edge cases (proposal 250)<br>
(David Goulet)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 20 Nov 2015 16:06:59 +0200<br>
From: George Kadianakis <<a \
href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>><br>
To: s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>><br>
Cc: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <<a href="mailto:87fv0069z0.fsf@riseup.net">87fv0069z0.fsf@riseup.net</a>><br>
Content-Type: text/plain<br>
<br>
s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
<br>
> Hello,<br>
><br>
> <snip><br>
><br>
> The idea of adding flags in the votes so each dirauth can advertise if<br>
> it is participating (has an opinion for the <current> SR or not) is<br>
> great and helps us build more defenses, probably make it easier in the<br>
> future too if we decide to change anything.<br>
><br>
> What if the consensus for SR calculation would define majority based<br>
> on dirauths actually participating (and advertising so with a flag in<br>
> the vote). Also, the participating or not participating flag should be<br>
> used per vote/consensus and split into:<br>
><br>
> a) we know current SR value for today so we vote it<br>
> or<br>
> we know previous SR value and we know for sure if we should follow the<br>
> disaster protocol or not (in case we are about to vote at 01:00 UTC).<br>
> so<br>
> We participate in the vote for <current SR>.<br>
><br>
> b) we are able to participate in this protocol run which will<br>
> calculate the SR value for next day (after 00:00 UTC) so we send our<br>
> commits/reveals.<br>
><br>
> This is useful in case we are a dirauth that joined at 00:30 UTC and<br>
> we couldn't get the _latest_ consensus (to find out if the 00:00 UTC<br>
> consensus was created, and if not, previous SR value so we can follow<br>
> the disaster procedure) we will not have an opinion for the <current><br>
> SR value at 01:00 UTC, but we can start participating in the protocol<br>
> run for the next day - send our commit values. Once we decided on a<br>
> <current> SR value for that day we save it and vote normally next \
time.<br> ><br>
> So, if we have 5 dirauths running/signing consensus in total, out of<br>
> which only 4 participate in the shared randomness protocol, the 4<br>
> participating ones should be able to create a valid consensus<br>
> themselves with the insurance that the 5th one won't break consensus.<br>
><br>
> One way to do this is: the dirauth which is not participating will<br>
> take the SR value voted by the majority of the participating dirauths<br>
> and include that in its consensus and sign. We need at least 3<br>
> dirauths agreeing on a SR value in order to accept it.<br>
><br>
> Is this crazy? It shouldn't open the door new attacks, since this<br>
> doesn't allow a single actor to game it, only the majority could game \
it.<br> ><br>
<br>
Thanks for the suggestions.<br>
<br>
Let me try to suggest a procedure here based on your ideas and some other ideas.<br>
<br>
[Notation: SRV = shared random value]<br>
<br>
The goal here is to minimize the edge cases during SRV calculation and disaster<br>
SRV calculation. The edge cases here appear because there is no clear view on<br>
whether other dirauths know the current or previous SRVs, or whether the SRV for<br>
this period was ever created. The disaster recovery scenario is especially<br>
annoying here.<br>
<br>
Here are some edge cases for example:<br>
<br>
* Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain any<br>
SR information (maybe because not enough SR-enabled dirauths participated at<br>
that time).<br>
<br>
Should the dirauth do the disaster recovery procedure, or just play it cool<br>
and put no SR information on the consensus? If it has to do disaster recovery,<br>
then what previous SRV does it use (the 01:00UTC consensus did not contain<br>
such info)?<br>
<br>
This type of edge case is my main concern, since with dirauths upgrading and<br>
going offline at random times, it's likely that we will eventually create \
a<br> consensus without SR info in the middle of the protocol run.<br>
<br>
* Dirauth boots up at 23:55UTC without having a previous consensus. It is<br>
supposed to vote and form a 00:00UTC consensus without knowing any previous<br>
SRVs. How does it figure out whether all the other dirauths are also<br>
bootstrapping, or whether the other dirauths actually know the previous SRVs?<br>
<br>
Here are some prerequisites for the logic I'm going to suggest. The two first<br>
suggestions are useful in any case, I think:<br>
<br>
- First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
previous/current SRVs they didn't know about from any consensus they \
fetch.<br> <br>
- We are also going to assume that we have some sort of "SR flag" on votes \
to<br> denote whether the dirauth participates in the protocol.<br>
<br>
- We are introducing another 'status' for shared random values (see \
[SRVOTE]).<br> <br>
Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be<br>
created, or it did not contain any SRV information, then it sets the status of<br>
"shared-rand-current-value" in its votes to "none".<br>
<br>
Now we are going to use the SRV lines in the votes as an indicator on how the<br>
consensus creation should play out.<br>
<br>
================================================================================<br>
<br>
Here is some logic for the consensus at 00:00UTC:<br>
<br>
if majority of votes have disabled the SR flag:<br>
then don't write anything SR-related to consensus<br>
exit<br>
<br>
If the majority of votes contain the previous SRV value:<br>
then calculate SRV as detailed in section [SRCALC]<br>
else:<br>
then calculate SRV as in [SRCALC] but with previous_SRV set to \
0<br> <br>
And here is some logic for all the other consensuses (to figure out when<br>
dirauths should perform the disaster procedure):<br>
<br>
if majority of votes have disabled the SR flag:<br>
then don't write anything SR-related to consensus<br>
exit<br>
<br>
if we know the current SRV:<br>
then write it on the consensus<br>
exit<br>
<br>
if the majority of votes have the current SRV status as "none" \
_AND_<br> those votes also contain the previous SRV value:<br>
then do the disaster SRV procedure<br>
else:<br>
then don't write anything SR-related to consensus<br>
<br>
================================================================================<br>
<br>
This _might_ work for fixing a good bunch of edge cases. But is it far too \
complex?<br> <br>
Should we just assume that these things will never happen on the real network<br>
and avoid baking additional complexity? What do you think? :/<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 20 Nov 2015 10:19:07 -0500<br>
From: David Goulet <<a \
href="mailto:dgoulet@ev0ke.net">dgoulet@ev0ke.net</a>><br>
To: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <20151120151907.GD10269@raoul><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On 20 Nov (16:06:59), George Kadianakis wrote:<br>
> s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
><br>
> > Hello,<br>
> ><br>
> > <snip><br>
> ><br>
> > The idea of adding flags in the votes so each dirauth can advertise if<br>
> > it is participating (has an opinion for the <current> SR or not) \
is<br> > > great and helps us build more defenses, probably make it easier in \
the<br> > > future too if we decide to change anything.<br>
> ><br>
> > What if the consensus for SR calculation would define majority based<br>
> > on dirauths actually participating (and advertising so with a flag in<br>
> > the vote). Also, the participating or not participating flag should be<br>
> > used per vote/consensus and split into:<br>
> ><br>
> > a) we know current SR value for today so we vote it<br>
> > or<br>
> > we know previous SR value and we know for sure if we should follow the<br>
> > disaster protocol or not (in case we are about to vote at 01:00 UTC).<br>
> > so<br>
> > We participate in the vote for <current SR>.<br>
> ><br>
> > b) we are able to participate in this protocol run which will<br>
> > calculate the SR value for next day (after 00:00 UTC) so we send our<br>
> > commits/reveals.<br>
> ><br>
> > This is useful in case we are a dirauth that joined at 00:30 UTC and<br>
> > we couldn't get the _latest_ consensus (to find out if the 00:00 \
UTC<br> > > consensus was created, and if not, previous SR value so we can \
follow<br> > > the disaster procedure) we will not have an opinion for the \
<current><br> > > SR value at 01:00 UTC, but we can start participating \
in the protocol<br> > > run for the next day - send our commit values. Once we \
decided on a<br> > > <current> SR value for that day we save it and vote \
normally next time.<br> > ><br>
> > So, if we have 5 dirauths running/signing consensus in total, out of<br>
> > which only 4 participate in the shared randomness protocol, the 4<br>
> > participating ones should be able to create a valid consensus<br>
> > themselves with the insurance that the 5th one won't break \
consensus.<br> > ><br>
> > One way to do this is: the dirauth which is not participating will<br>
> > take the SR value voted by the majority of the participating dirauths<br>
> > and include that in its consensus and sign. We need at least 3<br>
> > dirauths agreeing on a SR value in order to accept it.<br>
> ><br>
> > Is this crazy? It shouldn't open the door new attacks, since this<br>
> > doesn't allow a single actor to game it, only the majority could game \
it.<br> > ><br>
><br>
> Thanks for the suggestions.<br>
><br>
> Let me try to suggest a procedure here based on your ideas and some other \
ideas.<br> ><br>
> [Notation: SRV = shared random value]<br>
><br>
> The goal here is to minimize the edge cases during SRV calculation and \
disaster<br> > SRV calculation. The edge cases here appear because there is no \
clear view on<br> > whether other dirauths know the current or previous SRVs, or \
whether the SRV for<br> > this period was ever created. The disaster recovery \
scenario is especially<br> > annoying here.<br>
><br>
> Here are some edge cases for example:<br>
><br>
> * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain \
any<br> > SR information (maybe because not enough SR-enabled dirauths \
participated at<br> > that time).<br>
><br>
> Should the dirauth do the disaster recovery procedure, or just play it \
cool<br> > and put no SR information on the consensus? If it has to do \
disaster recovery,<br> > then what previous SRV does it use (the 01:00UTC \
consensus did not contain<br> > such info)?<br>
><br>
> This type of edge case is my main concern, since with dirauths upgrading \
and<br> > going offline at random times, it's likely that we will \
eventually create a<br> > consensus without SR info in the middle of the \
protocol run.<br> ><br>
> * Dirauth boots up at 23:55UTC without having a previous consensus. It is<br>
> supposed to vote and form a 00:00UTC consensus without knowing any \
previous<br> > SRVs. How does it figure out whether all the other dirauths are \
also<br> > bootstrapping, or whether the other dirauths actually know the \
previous SRVs?<br> ><br>
> Here are some prerequisites for the logic I'm going to suggest. The two \
first<br> > suggestions are useful in any case, I think:<br>
><br>
> - First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
> previous/current SRVs they didn't know about from any consensus they \
fetch.<br> <br>
Yes ++.<br>
<br>
A dirauth booting up should always try to learn the current and previous<br>
SRV from the latest consensus (< 24h) and update the disk state<br>
accordingly _even_ if the disk state has SRV values in there. We should<br>
trust the consensus voted by majority before our disk state imo.<br>
<br>
><br>
> - We are also going to assume that we have some sort of "SR flag" on \
votes to<br> > denote whether the dirauth participates in the protocol.<br>
<br>
The requirements for having that flag "on" or "off" eludes me a \
bit. I<br> assume that this SR flag is "on" when a dirauth thinks its able \
to<br> compute a valid SRV that is I have enough commits. We can't make \
"having<br> the previous SRV" a requirement else we will never bootstrap \
properly<br> ever since in the first runs, previous SRV is alway 0.<br>
<br>
><br>
> - We are introducing another 'status' for shared random values (see \
[SRVOTE]).<br> ><br>
> Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be<br>
> created, or it did not contain any SRV information, then it sets the status \
of<br> > "shared-rand-current-value" in its votes to \
"none".<br> <br>
Hrm... I'm wondering here if "none" status is instead the same of \
having<br> the dirauth putting the disaster value in the vote?<br>
<br>
I would argue that a dirauth should _always_ try to compute a SR value<br>
at any time (even when booting). Between having no line because we<br>
couldn't compute due to lack of commits or a line that is the disaster,<br>
I think the former simplifies things that is "We always have a SRV value<br>
at 00:00 from a dirauth".<br>
<br>
Here is what I propose:<br>
<br>
1) Like you said, we always try to learn SRV values from previous<br>
consensus. If we can't get one from a consensus or our state, compute<br>
disaster at 00:00.<br>
<br>
2) We do _not_ use a SR flag for vote, a dirauth always tries to compute<br>
a current SRV value at 00:00. If it's 13:00, it simply doesn't put<br>
anything in the vote since no SRV data.<br>
<br>
The big issue I see here is when a dirauth does _not_ have the previous<br>
SRV. Without it, both disaster and current SRV computation will end up<br>
not matching the majority. So let's explore this binary state:<br>
<br>
- I have the previous SRV (either I can get it from my state or<br>
consensus).<br>
<br>
This seems a non issue, dirauth will use it, carry it in the vote and<br>
compute the current SRV if enough commits have been seen. At 00:00, if<br>
majority wasn't reached for the current SRV value, we have a consensus<br>
without it which is a valid use case but we at least have the previous<br>
one in the consensus flagged as non-fresh so it can be used for<br>
disaster or SRV computation at the next protocol run.<br>
<br>
- I don't have a previous SRV (couldn't get it in the latest consensus<br>
and I have _no_ disk state).<br>
<br>
For instance, if this happens at 23:30, a dirauth won't have the<br>
chance to participate in the SR protocol because it didn't see any<br>
commits to compute SRV value thus disaster mode engage.<br>
<br>
If that dirauth was the 5th one out of 9 (meaning the majority<br>
breaker), we end up with no SRV values at all at 00:00 (not even the<br>
previous SRV since only 4/9 had it). So a new protocol run starts,<br>
we'll end up with a valid current SRV in 24 hours and both values in<br>
48 hours. Essentially, we end up back in bootstrap mode.<br>
<br>
IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values<br>
that aren't in the 00:00 consensus.<br>
<br>
Question is, how big of a deal it is to have this issue where if we<br>
don't reach majority because a dirauth rebooted and for some magical<br>
reason didn't get the latest consensus to at least get the previous<br>
SRV, we return in bootstrap?<br>
<br>
Cheers!<br>
David<br>
<br>
><br>
> Now we are going to use the SRV lines in the votes as an indicator on how \
the<br> > consensus creation should play out.<br>
><br>
> ================================================================================<br>
><br>
> Here is some logic for the consensus at 00:00UTC:<br>
><br>
> if majority of votes have disabled the SR flag:<br>
> then don't write anything SR-related to consensus<br>
> exit<br>
><br>
> If the majority of votes contain the previous SRV value:<br>
> then calculate SRV as detailed in section [SRCALC]<br>
> else:<br>
> then calculate SRV as in [SRCALC] but with previous_SRV \
set to 0<br> ><br>
> And here is some logic for all the other consensuses (to figure out when<br>
> dirauths should perform the disaster procedure):<br>
><br>
> if majority of votes have disabled the SR flag:<br>
> then don't write anything SR-related to consensus<br>
> exit<br>
><br>
> if we know the current SRV:<br>
> then write it on the consensus<br>
> exit<br>
><br>
> if the majority of votes have the current SRV status as "none" \
_AND_<br> > those votes also contain the previous SRV value:<br>
> then do the disaster SRV procedure<br>
> else:<br>
> then don't write anything SR-related to consensus<br>
><br>
> ================================================================================<br>
><br>
> This _might_ work for fixing a good bunch of edge cases. But is it far too \
complex?<br> ><br>
> Should we just assume that these things will never happen on the real \
network<br> > and avoid baking additional complexity? What do you think? :/<br>
><br>
><br>
> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" \
rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 603 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/c02f52ca/attachment-0001.sig" \
rel="noreferrer" target="_blank">http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/c02f52ca/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 20 Nov 2015 11:24:24 -0500<br>
From: David Goulet <<a \
href="mailto:dgoulet@ev0ke.net">dgoulet@ev0ke.net</a>><br>
To: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <20151120162424.GE10269@raoul><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On 20 Nov (10:19:07), David Goulet wrote:<br>
> On 20 Nov (16:06:59), George Kadianakis wrote:<br>
> > s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
> ><br>
> > > Hello,<br>
> > ><br>
> > > <snip><br>
> > ><br>
> > > The idea of adding flags in the votes so each dirauth can advertise \
if<br> > > > it is participating (has an opinion for the <current> SR \
or not) is<br> > > > great and helps us build more defenses, probably make \
it easier in the<br> > > > future too if we decide to change anything.<br>
> > ><br>
> > > What if the consensus for SR calculation would define majority \
based<br> > > > on dirauths actually participating (and advertising so with \
a flag in<br> > > > the vote). Also, the participating or not participating \
flag should be<br> > > > used per vote/consensus and split into:<br>
> > ><br>
> > > a) we know current SR value for today so we vote it<br>
> > > or<br>
> > > we know previous SR value and we know for sure if we should follow \
the<br> > > > disaster protocol or not (in case we are about to vote at \
01:00 UTC).<br> > > > so<br>
> > > We participate in the vote for <current SR>.<br>
> > ><br>
> > > b) we are able to participate in this protocol run which will<br>
> > > calculate the SR value for next day (after 00:00 UTC) so we send \
our<br> > > > commits/reveals.<br>
> > ><br>
> > > This is useful in case we are a dirauth that joined at 00:30 UTC \
and<br> > > > we couldn't get the _latest_ consensus (to find out if the \
00:00 UTC<br> > > > consensus was created, and if not, previous SR value so \
we can follow<br> > > > the disaster procedure) we will not have an opinion \
for the <current><br> > > > SR value at 01:00 UTC, but we can start \
participating in the protocol<br> > > > run for the next day - send our \
commit values. Once we decided on a<br> > > > <current> SR value for \
that day we save it and vote normally next time.<br> > > ><br>
> > > So, if we have 5 dirauths running/signing consensus in total, out \
of<br> > > > which only 4 participate in the shared randomness protocol, the \
4<br> > > > participating ones should be able to create a valid \
consensus<br> > > > themselves with the insurance that the 5th one won't \
break consensus.<br> > > ><br>
> > > One way to do this is: the dirauth which is not participating will<br>
> > > take the SR value voted by the majority of the participating \
dirauths<br> > > > and include that in its consensus and sign. We need at \
least 3<br> > > > dirauths agreeing on a SR value in order to accept it.<br>
> > ><br>
> > > Is this crazy? It shouldn't open the door new attacks, since \
this<br> > > > doesn't allow a single actor to game it, only the \
majority could game it.<br> > > ><br>
> ><br>
> > Thanks for the suggestions.<br>
> ><br>
> > Let me try to suggest a procedure here based on your ideas and some other \
ideas.<br> > ><br>
> > [Notation: SRV = shared random value]<br>
> ><br>
> > The goal here is to minimize the edge cases during SRV calculation and \
disaster<br> > > SRV calculation. The edge cases here appear because there is \
no clear view on<br> > > whether other dirauths know the current or previous \
SRVs, or whether the SRV for<br> > > this period was ever created. The disaster \
recovery scenario is especially<br> > > annoying here.<br>
> ><br>
> > Here are some edge cases for example:<br>
> ><br>
> > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain \
any<br> > > SR information (maybe because not enough SR-enabled dirauths \
participated at<br> > > that time).<br>
> ><br>
> > Should the dirauth do the disaster recovery procedure, or just play it \
cool<br> > > and put no SR information on the consensus? If it has to do \
disaster recovery,<br> > > then what previous SRV does it use (the 01:00UTC \
consensus did not contain<br> > > such info)?<br>
> ><br>
> > This type of edge case is my main concern, since with dirauths \
upgrading and<br> > > going offline at random times, it's likely that \
we will eventually create a<br> > > consensus without SR info in the middle \
of the protocol run.<br> > ><br>
> > * Dirauth boots up at 23:55UTC without having a previous consensus. It \
is<br> > > supposed to vote and form a 00:00UTC consensus without knowing \
any previous<br> > > SRVs. How does it figure out whether all the other \
dirauths are also<br> > > bootstrapping, or whether the other dirauths \
actually know the previous SRVs?<br> > ><br>
> > Here are some prerequisites for the logic I'm going to suggest. The two \
first<br> > > suggestions are useful in any case, I think:<br>
> ><br>
> > - First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
> > previous/current SRVs they didn't know about from any consensus \
they fetch.<br> ><br>
> Yes ++.<br>
><br>
> A dirauth booting up should always try to learn the current and previous<br>
> SRV from the latest consensus (< 24h) and update the disk state<br>
> accordingly _even_ if the disk state has SRV values in there. We should<br>
> trust the consensus voted by majority before our disk state imo.<br>
><br>
> ><br>
> > - We are also going to assume that we have some sort of "SR flag" \
on votes to<br> > > denote whether the dirauth participates in the \
protocol.<br> ><br>
> The requirements for having that flag "on" or "off" eludes \
me a bit. I<br> > assume that this SR flag is "on" when a dirauth thinks \
its able to<br> > compute a valid SRV that is I have enough commits. We can't \
make "having<br> > the previous SRV" a requirement else we will never \
bootstrap properly<br> > ever since in the first runs, previous SRV is alway \
0.<br> ><br>
> ><br>
> > - We are introducing another 'status' for shared random values (see \
[SRVOTE]).<br> > ><br>
> > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to \
be<br> > > created, or it did not contain any SRV information, then it sets \
the status of<br> > > "shared-rand-current-value" in its votes to \
"none".<br> ><br>
> Hrm... I'm wondering here if "none" status is instead the same of \
having<br> > the dirauth putting the disaster value in the vote?<br>
><br>
> I would argue that a dirauth should _always_ try to compute a SR value<br>
> at any time (even when booting). Between having no line because we<br>
> couldn't compute due to lack of commits or a line that is the disaster,<br>
> I think the former simplifies things that is "We always have a SRV \
value<br> > at 00:00 from a dirauth".<br>
><br>
> Here is what I propose:<br>
><br>
> 1) Like you said, we always try to learn SRV values from previous<br>
> consensus. If we can't get one from a consensus or our state, compute<br>
> disaster at 00:00.<br>
><br>
> 2) We do _not_ use a SR flag for vote, a dirauth always tries to compute<br>
> a current SRV value at 00:00. If it's 13:00, it simply doesn't put<br>
> anything in the vote since no SRV data.<br>
><br>
> The big issue I see here is when a dirauth does _not_ have the previous<br>
> SRV. Without it, both disaster and current SRV computation will end up<br>
> not matching the majority. So let's explore this binary state:<br>
><br>
> - I have the previous SRV (either I can get it from my state or<br>
> consensus).<br>
><br>
> This seems a non issue, dirauth will use it, carry it in the vote and<br>
> compute the current SRV if enough commits have been seen. At 00:00, if<br>
> majority wasn't reached for the current SRV value, we have a \
consensus<br> > without it which is a valid use case but we at least have the \
previous<br> > one in the consensus flagged as non-fresh so it can be used \
for<br> > disaster or SRV computation at the next protocol run.<br>
><br>
> - I don't have a previous SRV (couldn't get it in the latest \
consensus<br> > and I have _no_ disk state).<br>
><br>
> For instance, if this happens at 23:30, a dirauth won't have the<br>
> chance to participate in the SR protocol because it didn't see any<br>
> commits to compute SRV value thus disaster mode engage.<br>
><br>
> If that dirauth was the 5th one out of 9 (meaning the majority<br>
> breaker), we end up with no SRV values at all at 00:00 (not even the<br>
> previous SRV since only 4/9 had it). So a new protocol run starts,<br>
> we'll end up with a valid current SRV in 24 hours and both values in<br>
> 48 hours. Essentially, we end up back in bootstrap mode.<br>
><br>
> IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values<br>
> that aren't in the 00:00 consensus.<br>
><br>
> Question is, how big of a deal it is to have this issue where if we<br>
> don't reach majority because a dirauth rebooted and for some magical<br>
> reason didn't get the latest consensus to at least get the previous<br>
> SRV, we return in bootstrap?<br>
<br>
Ok more thoughts on this, asn asked that I make an algorithm so here is<br>
a try at that:<br>
<br>
-- Booting up Conditions --<br>
<br>
- A dirauth MUST try to acquire both previous and current SRV from<br>
the last consensus. If it can't, get it from disk state. If<br>
nothing is available, none exists for this protocol run.<br>
<br>
-- Algorithm --<br>
<br>
At 16:00 (arbitrary time which is _not_ the current SRV calculation):<br>
<br>
# Voting<br>
if dirauth has previous SRV:<br>
put it in vote<br>
if dirauth has current SRV:<br>
put it in vote<br>
<br>
Output: Consensus is created<br>
<br>
# Consensus<br>
(This goes for both previous and current SRV)<br>
if SRV in consensus:<br>
dirauth MUST keep it even if the one they have doesn't match.<br>
Majority has decided what should be used.<br>
else:<br>
dirauth MUST discard the SRV it has.<br>
<br>
At 00:00<br>
<br>
# Voting<br>
if current SRV can't be created because lack of commits:<br>
current SRV == disaster mode (previous SRV or not)<br>
else:<br>
compute current SRV (with or without a previous SRV)<br>
<br>
(Proceed like the 16:00 period)<br>
<br>
# Consensus<br>
if majority agrees on SR value(s):<br>
put in consensus<br>
else:<br>
No SR value(s) in consensus<br>
<br>
Output: consensus is created<br>
<br>
(Proceed like the 16:00 period)<br>
<br>
<br>
Side effect of only keeping SRV that are in the consensus. If one voting<br>
round goes bad for X reason and consensus end up with no SRV, we end up<br>
in bootstrapping mode that is no previous nor current SRV in the<br>
consensus which is problematic because for 48 hours, we won't have a<br>
previous SRV which is the one used by everyone.<br>
<br>
I don't see a way to get out of this because consensus is decided from<br>
the votes deterministically thus if not enough vote for SR values, we'll<br>
end up with a consensus with none so this is why client/HS have to<br>
fallback to a disaster value by themselves I think which can NOT be<br>
based on the previous SRV.<br>
<br>
David<br>
<br>
><br>
> Cheers!<br>
> David<br>
><br>
> ><br>
> > Now we are going to use the SRV lines in the votes as an indicator on how \
the<br> > > consensus creation should play out.<br>
> ><br>
> > ================================================================================<br>
> ><br>
> > Here is some logic for the consensus at 00:00UTC:<br>
> ><br>
> > if majority of votes have disabled the SR flag:<br>
> > then don't write anything SR-related to \
consensus<br> > > exit<br>
> ><br>
> > If the majority of votes contain the previous SRV value:<br>
> > then calculate SRV as detailed in section \
[SRCALC]<br> > > else:<br>
> > then calculate SRV as in [SRCALC] but with \
previous_SRV set to 0<br> > ><br>
> > And here is some logic for all the other consensuses (to figure out \
when<br> > > dirauths should perform the disaster procedure):<br>
> ><br>
> > if majority of votes have disabled the SR flag:<br>
> > then don't write anything SR-related to \
consensus<br> > > exit<br>
> ><br>
> > if we know the current SRV:<br>
> > then write it on the consensus<br>
> > exit<br>
> ><br>
> > if the majority of votes have the current SRV status as \
"none" _AND_<br> > > those votes also contain the \
previous SRV value:<br> > > then do the disaster SRV \
procedure<br> > > else:<br>
> > then don't write anything SR-related to \
consensus<br> > ><br>
> > ================================================================================<br>
> ><br>
> > This _might_ work for fixing a good bunch of edge cases. But is it far too \
complex?<br> > ><br>
> > Should we just assume that these things will never happen on the real \
network<br> > > and avoid baking additional complexity? What do you think? \
:/<br> > ><br>
> ><br>
> > _______________________________________________<br>
> > tor-dev mailing list<br>
> > <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> > <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" \
rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
<br>
<br>
> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" \
rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 603 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/68e8133d/attachment.sig" \
rel="noreferrer" target="_blank">http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/68e8133d/attachment.sig</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" \
rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of tor-dev Digest, Vol 58, Issue 39<br>
***************************************<br>
</blockquote></div><br></div></div>
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic