[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