prop291: dos2unix the file so we get a Unix format

No change, just removes the annoying ^M at the end of each line.

Signed-off-by: David Goulet <dgoulet@torproject.org>

1 files changed, 251 insertions, 251 deletions

diff --git a/proposals/291-two-guard-nodes.txt b/proposals/291-two-guard-nodes.txt
index a900ee9..dc0aa74 100644
--- a/proposals/291-two-guard-nodes.txt
+++ b/proposals/291-two-guard-nodes.txt
@@ -1,251 +1,251 @@
-Filename: 291-two-guard-nodes.txt

-Title: The move to two guard nodes

-Author: Mike Perry

-Created: 2018-03-22

-Supersedes: Proposal 236

-Status: Open

-

-0. Background

-

-  Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3].

-

-  We made this change primarily to limit points of observability of entry

-  into the Tor network for clients and onion services, as well as to

-  reduce the ability of an adversary to track clients as they move from

-  one internet connection to another by their choice of guards.

-

-

-1. Proposed changes

-

-1.1. Switch to two guards per client

-

-  When this proposal becomes effective, clients will switch to using

-  two guard nodes. The guard node selection algorithms of Proposal 271

-  will remain unchanged. Instead of having one primary guard "in use",

-  Tor clients will always use two.

-

-  This will be accomplished by setting the guard-n-primary-guards-to-use

-  consensus parameter to 2, as well as guard-n-primary-guards to 2.

-  (Section 3.1 covers the reason for both parameters). This is equivalent

-  to using the torrc option NumEntryGuards=3D2, which can be used for

-  testing behavior prior to the consensus update.

-

-1.2. Enforce Tor's path restrictions across this guard layer

-

-  In order to ensure that Tor can always build circuits using two guards

-  without resorting to a third, they must be chosen such that Tor's path

-  restrictions could still build a path with at least one of them,

-  regardless of the other nodes in the path.

-

-  In other words, we must ensure that both guards are not chosen from the

-  same /16 or the same node family. In this way, Tor will always be able to

-  build a path using these guards, preventing the use of a third guard.

-

-

-2. Discussion

-

-2.1. Why two guards?

-

-  The main argument for switching to two guards is that because of Tor's

-  path restrictions, we're already using two guards, but we're using them

-  in a suboptimal and potentially dangerous way.

-

-  Tor's path restrictions enforce the condition that the same node cannot

-  appear twice in the same circuit, nor can nodes from the same /16 subnet

-  or node family be used in the same circuit.

-

-  Tor's paths are also built such that the exit node is chosen first and

-  held fixed during guard node choice, as are the IP, HSDIR, and RPs for

-  onion services. This means that whenever one of these nodes happens to

-  be the guard[4], or be in the same /16 or node family as the guard, Tor

-  will build that circuit using a second "primary" guard, as per proposal

-  271[7].

-

-  Worse still, the choice of RP, IP, and exit can all be controlled by an

-  adversary (to varying degrees), enabling them to force the use of a

-  second guard at will.

-

-  Because this happens somewhat infrequently in normal operation, a fresh

-  TLS connection will typically be created to the second "primary" guard,

-  and that TLS connection will be used only for the circuit for that

-  particular request. This property makes all sorts of traffic analysis

-  attacks easier, because this TLS connection will not benefit from any

-  multiplexing.

-

-  This is more serious than traffic injection via an already in-use

-  guard because the lack of multiplexing means that the data retention

-  level required to gain information from this activity is very low, and

-  may exist for other reasons. To gain information from this behavior, an

-  adversary needs only connection 5-tuples + timestamps, as opposed to

-  detailed timeseries data that is polluted by other concurrent activity

-  and padding.

-

-  In the most severe form of this attack, the adversary can take a suspect

-  list of Tor client IP addresses (or the list of all Guard node IP addresses)

-  and observe when secondary Tor connections are made to them at the time when

-  they cycle through all guards as RPs for connections to an onion

-  service. This adversary does not require collusion on the part of observers

-  beyond the ability to provide 5-tuple connection logs (which ISPs may retain

-  for reasons such as netflow accounting, IDS, or DoS protection systems).

-

-  A fully passive adversary can also make use of this behavior. Clients

-  unlucky enough to pick guard nodes in heavily used /16s or in large node

-  families will tend to make use of a second guard more frequently even

-  without effort from the adversary. In these cases, the lack of

-  multiplexing also means that observers along the path to this secondary

-  guard gain more information per observation.

-

-2.2. Why not MOAR guards?

-

-  We do not want to increase the number of observation points for client

-  activity into the Tor network[1]. We merely want better multiplexing for

-  the cases where this already happens.

-

-2.3. Can you put some numbers on that?

-

-  The Changing of the Guards[13] paper studies this from a few different

-  angles, but one of the crucially missing graphs is how long a client

-  can expect to run with N guards before it chooses a malicious guard.

-

-  However, we do have tables in section 3.2.1 of proposal 247 that cover

-  this[14]. There are three tables there: one for a 1% adversary, one for

-  a 5% adversary, and one for a 10% adversary. You can see the probability

-  of adversary success for one and two guards in terms of the number of

-  rotations needed before the adversary's node is chosen. Not surprisingly,

-  the two guard adversary gets to compromise clients roughly twice as

-  quickly, but the timescales are still rather large even for the 10%

-  adversary: they only have 50% chance of success after 4 rotations, which

-  will take about 14 months with Tor's 3.5 month guard rotation.

-

-2.4. What about guard fingerprinting?

-

-  More guards also means more fingerprinting[8]. However, even one guard

-  may be enough to fingerprint a user who moves around in the same area,

-  if that guard is low bandwidth or there are not many Tor users in that

-  area.

-

-  Furthermore, our use of separate directory guards (and three of them)

-  means that we're not really changing the situation much with the

-  addition of another regular guard. Right now, directory guard use alone

-  is enough to track all Tor users across the entire world.

-

-  While the directory guard problem could be fixed[12] (and should be

-  fixed), it is still the case that another mechanism should be used for

-  the general problem of guard-vs-location management[9].

-

-

-3. Alternatives

-

-  There are two other solutions that also avoid the use of secondary guard

-  in the path restriction case.

-

-3.1. Eliminate path restrictions entirely

-

-  If Tor decided to stop enforcing /16, node family, and also allowed the

-  guard node to be chosen twice in the path, then under normal conditions,

-  it should retain the use of its primary guard.

-

-  This approach is not as extreme as it seems on face. In fact, it is hard

-  to come up with arguments against removing these restrictions. Tor's

-  /16 restriction is of questionable utility against monitoring, and it can

-  be argued that since only good actors use node family, it gives influence

-  over path selection to bad actors in ways that are worse than the benefit

-  it provides to paths through good actors[10,11].

-

-  However, while removing path restrictions will solve the immediate

-  problem, it will not address other instances where Tor temporarily opts

-  use a second guard due to congestion, OOM, or failure of its primary

-  guard, and we're still running into bugs where this can be adversarially

-  controlled or just happen randomly[5].

-

-  While using two guards means twice the surface area for these types of

-  bugs, it also means that instances where they happen simultaneously on

-  both guards (thus forcing a third guard) are much less likely than with

-  just one guard. (In the passive adversary model, consider that one guard

-  fails at any point with probability P1. If we assume that such passive

-  failures are independent events, both guards would fail concurrently

-  with probability P1*P2. Even if the events are correlated, the maximum

-  chance of concurrent failure is still MIN(P1,P2)).

-

-  Note that for this analysis to hold, we have to ensure that nodes that

-  are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause

-  us to consider other primary guards beyond than the two we have chosen.

-  This is accomplished by setting guard-n-primary-guards to 2 (in addition

-  to setting guard-n-primary-guards-to-use to 2). With this parameter

-  set, the proposal 271 algorithm will avoid considering more than our two

-  guards, unless *both* are down at once.

-

-3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs

-

-  Similar to 3.1, we could instead forbid the use of Guard-flagged nodes

-  for the exit, IP, RP, and HSDIR positions.

-

-  This solution has two problems: First, like 3.1, it also does not handle

-  the case where resource exhaustion could force the use of a second

-  guard. Second, it requires clients to upgrade to the new behavior and

-  stop using Guard flagged nodes before it can be deployed.

-

-

-4. The future is confluxed

-

-  An additional benefit of using a second guard is that it enables us to

-  eventually use conflux[6].

-

-  Conflux works by giving circuits a 256bit cookie that is sent to the

-  exit/RP, and circuits that are then built to the same exit/RP with the

-  same cookie can then be fused together. Throughput estimates are used to

-  balance traffic between these circuits, depending on their performance.

-

-  We have unfortunately signaled to the research community that conflux is

-  not worth pursuing, because of our insistence on a single guard. While

-  not relevant to this proposal (indeed, conflux requires its own proposal

-  and also concurrent research), it is worth noting that whichever way we

-  go here, the door remains open to conflux because of its utility against

-  similar issues.

-

-  If our conflux implementation includes packet acking, then circuits can

-  still survive the loss of one guard node due to DoS, OOM, or other

-  failures because the second half of the path will remain open and

-  usable (see the probability of concurrent failure arguments in Section

-  3.1).

-

-  If exits remember this cookie for a short period of time after the last

-  circuit is closed, the technique can be used to protect against

-  DoS/OOM/guard downtime conditions that take down both guard nodes or

-  destroy many circuits to confirm both guard node choices. In these

-  cases, circuits could be rebuilt along an alternate path and resumed

-  without end-to-end circuit connectivity loss. This same technique will

-  also make things like ephemeral bridges (ie Snowflake/Flashproxy) more

-  usable, because bridge uptime will no longer be so crucial to usability.

-  It will also improve mobile usability by allowing us to resume

-  connections after mobile Tor apps are briefly suspended, or if the user

-  switches between cell and wifi networks.

-

-  Furthermore, it is likely that conflux will also be useful against traffic

-  analysis and congestion attacks. Since the load balancing is dynamic and

-  hard to predict by an external observer and also increases overall

-  traffic multiplexing, traffic correlation and website traffic

-  fingerprinting attacks will become harder, because the adversary can no

-  longer be sure what percentage of the traffic they have seen (depending

-  on their position and other potential concurrent activity).  Similarly,

-  it should also help dampen congestion attacks, since traffic will

-  automatically shift away from a congested guard.

-

-

-

-References:

-

-1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters

-2. https://trac.torproject.org/projects/tor/ticket/12206

-3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-node.txt

-4. https://trac.torproject.org/projects/tor/ticket/14917

-5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14

-6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf

-7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt

-8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3

-9. https://tails.boum.org/blueprint/persistent_Tor_state/

-10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3

-11. https://bugs.torproject.org/15060

-12. https://trac.torproject.org/projects/tor/ticket/10969

-13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf

-14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt

+Filename: 291-two-guard-nodes.txt
+Title: The move to two guard nodes
+Author: Mike Perry
+Created: 2018-03-22
+Supersedes: Proposal 236
+Status: Open
+
+0. Background
+
+  Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3].
+
+  We made this change primarily to limit points of observability of entry
+  into the Tor network for clients and onion services, as well as to
+  reduce the ability of an adversary to track clients as they move from
+  one internet connection to another by their choice of guards.
+
+
+1. Proposed changes
+
+1.1. Switch to two guards per client
+
+  When this proposal becomes effective, clients will switch to using
+  two guard nodes. The guard node selection algorithms of Proposal 271
+  will remain unchanged. Instead of having one primary guard "in use",
+  Tor clients will always use two.
+
+  This will be accomplished by setting the guard-n-primary-guards-to-use
+  consensus parameter to 2, as well as guard-n-primary-guards to 2.
+  (Section 3.1 covers the reason for both parameters). This is equivalent
+  to using the torrc option NumEntryGuards=3D2, which can be used for
+  testing behavior prior to the consensus update.
+
+1.2. Enforce Tor's path restrictions across this guard layer
+
+  In order to ensure that Tor can always build circuits using two guards
+  without resorting to a third, they must be chosen such that Tor's path
+  restrictions could still build a path with at least one of them,
+  regardless of the other nodes in the path.
+
+  In other words, we must ensure that both guards are not chosen from the
+  same /16 or the same node family. In this way, Tor will always be able to
+  build a path using these guards, preventing the use of a third guard.
+
+
+2. Discussion
+
+2.1. Why two guards?
+
+  The main argument for switching to two guards is that because of Tor's
+  path restrictions, we're already using two guards, but we're using them
+  in a suboptimal and potentially dangerous way.
+
+  Tor's path restrictions enforce the condition that the same node cannot
+  appear twice in the same circuit, nor can nodes from the same /16 subnet
+  or node family be used in the same circuit.
+
+  Tor's paths are also built such that the exit node is chosen first and
+  held fixed during guard node choice, as are the IP, HSDIR, and RPs for
+  onion services. This means that whenever one of these nodes happens to
+  be the guard[4], or be in the same /16 or node family as the guard, Tor
+  will build that circuit using a second "primary" guard, as per proposal
+  271[7].
+
+  Worse still, the choice of RP, IP, and exit can all be controlled by an
+  adversary (to varying degrees), enabling them to force the use of a
+  second guard at will.
+
+  Because this happens somewhat infrequently in normal operation, a fresh
+  TLS connection will typically be created to the second "primary" guard,
+  and that TLS connection will be used only for the circuit for that
+  particular request. This property makes all sorts of traffic analysis
+  attacks easier, because this TLS connection will not benefit from any
+  multiplexing.
+
+  This is more serious than traffic injection via an already in-use
+  guard because the lack of multiplexing means that the data retention
+  level required to gain information from this activity is very low, and
+  may exist for other reasons. To gain information from this behavior, an
+  adversary needs only connection 5-tuples + timestamps, as opposed to
+  detailed timeseries data that is polluted by other concurrent activity
+  and padding.
+
+  In the most severe form of this attack, the adversary can take a suspect
+  list of Tor client IP addresses (or the list of all Guard node IP addresses)
+  and observe when secondary Tor connections are made to them at the time when
+  they cycle through all guards as RPs for connections to an onion
+  service. This adversary does not require collusion on the part of observers
+  beyond the ability to provide 5-tuple connection logs (which ISPs may retain
+  for reasons such as netflow accounting, IDS, or DoS protection systems).
+
+  A fully passive adversary can also make use of this behavior. Clients
+  unlucky enough to pick guard nodes in heavily used /16s or in large node
+  families will tend to make use of a second guard more frequently even
+  without effort from the adversary. In these cases, the lack of
+  multiplexing also means that observers along the path to this secondary
+  guard gain more information per observation.
+
+2.2. Why not MOAR guards?
+
+  We do not want to increase the number of observation points for client
+  activity into the Tor network[1]. We merely want better multiplexing for
+  the cases where this already happens.
+
+2.3. Can you put some numbers on that?
+
+  The Changing of the Guards[13] paper studies this from a few different
+  angles, but one of the crucially missing graphs is how long a client
+  can expect to run with N guards before it chooses a malicious guard.
+
+  However, we do have tables in section 3.2.1 of proposal 247 that cover
+  this[14]. There are three tables there: one for a 1% adversary, one for
+  a 5% adversary, and one for a 10% adversary. You can see the probability
+  of adversary success for one and two guards in terms of the number of
+  rotations needed before the adversary's node is chosen. Not surprisingly,
+  the two guard adversary gets to compromise clients roughly twice as
+  quickly, but the timescales are still rather large even for the 10%
+  adversary: they only have 50% chance of success after 4 rotations, which
+  will take about 14 months with Tor's 3.5 month guard rotation.
+
+2.4. What about guard fingerprinting?
+
+  More guards also means more fingerprinting[8]. However, even one guard
+  may be enough to fingerprint a user who moves around in the same area,
+  if that guard is low bandwidth or there are not many Tor users in that
+  area.
+
+  Furthermore, our use of separate directory guards (and three of them)
+  means that we're not really changing the situation much with the
+  addition of another regular guard. Right now, directory guard use alone
+  is enough to track all Tor users across the entire world.
+
+  While the directory guard problem could be fixed[12] (and should be
+  fixed), it is still the case that another mechanism should be used for
+  the general problem of guard-vs-location management[9].
+
+
+3. Alternatives
+
+  There are two other solutions that also avoid the use of secondary guard
+  in the path restriction case.
+
+3.1. Eliminate path restrictions entirely
+
+  If Tor decided to stop enforcing /16, node family, and also allowed the
+  guard node to be chosen twice in the path, then under normal conditions,
+  it should retain the use of its primary guard.
+
+  This approach is not as extreme as it seems on face. In fact, it is hard
+  to come up with arguments against removing these restrictions. Tor's
+  /16 restriction is of questionable utility against monitoring, and it can
+  be argued that since only good actors use node family, it gives influence
+  over path selection to bad actors in ways that are worse than the benefit
+  it provides to paths through good actors[10,11].
+
+  However, while removing path restrictions will solve the immediate
+  problem, it will not address other instances where Tor temporarily opts
+  use a second guard due to congestion, OOM, or failure of its primary
+  guard, and we're still running into bugs where this can be adversarially
+  controlled or just happen randomly[5].
+
+  While using two guards means twice the surface area for these types of
+  bugs, it also means that instances where they happen simultaneously on
+  both guards (thus forcing a third guard) are much less likely than with
+  just one guard. (In the passive adversary model, consider that one guard
+  fails at any point with probability P1. If we assume that such passive
+  failures are independent events, both guards would fail concurrently
+  with probability P1*P2. Even if the events are correlated, the maximum
+  chance of concurrent failure is still MIN(P1,P2)).
+
+  Note that for this analysis to hold, we have to ensure that nodes that
+  are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause
+  us to consider other primary guards beyond than the two we have chosen.
+  This is accomplished by setting guard-n-primary-guards to 2 (in addition
+  to setting guard-n-primary-guards-to-use to 2). With this parameter
+  set, the proposal 271 algorithm will avoid considering more than our two
+  guards, unless *both* are down at once.
+
+3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs
+
+  Similar to 3.1, we could instead forbid the use of Guard-flagged nodes
+  for the exit, IP, RP, and HSDIR positions.
+
+  This solution has two problems: First, like 3.1, it also does not handle
+  the case where resource exhaustion could force the use of a second
+  guard. Second, it requires clients to upgrade to the new behavior and
+  stop using Guard flagged nodes before it can be deployed.
+
+
+4. The future is confluxed
+
+  An additional benefit of using a second guard is that it enables us to
+  eventually use conflux[6].
+
+  Conflux works by giving circuits a 256bit cookie that is sent to the
+  exit/RP, and circuits that are then built to the same exit/RP with the
+  same cookie can then be fused together. Throughput estimates are used to
+  balance traffic between these circuits, depending on their performance.
+
+  We have unfortunately signaled to the research community that conflux is
+  not worth pursuing, because of our insistence on a single guard. While
+  not relevant to this proposal (indeed, conflux requires its own proposal
+  and also concurrent research), it is worth noting that whichever way we
+  go here, the door remains open to conflux because of its utility against
+  similar issues.
+
+  If our conflux implementation includes packet acking, then circuits can
+  still survive the loss of one guard node due to DoS, OOM, or other
+  failures because the second half of the path will remain open and
+  usable (see the probability of concurrent failure arguments in Section
+  3.1).
+
+  If exits remember this cookie for a short period of time after the last
+  circuit is closed, the technique can be used to protect against
+  DoS/OOM/guard downtime conditions that take down both guard nodes or
+  destroy many circuits to confirm both guard node choices. In these
+  cases, circuits could be rebuilt along an alternate path and resumed
+  without end-to-end circuit connectivity loss. This same technique will
+  also make things like ephemeral bridges (ie Snowflake/Flashproxy) more
+  usable, because bridge uptime will no longer be so crucial to usability.
+  It will also improve mobile usability by allowing us to resume
+  connections after mobile Tor apps are briefly suspended, or if the user
+  switches between cell and wifi networks.
+
+  Furthermore, it is likely that conflux will also be useful against traffic
+  analysis and congestion attacks. Since the load balancing is dynamic and
+  hard to predict by an external observer and also increases overall
+  traffic multiplexing, traffic correlation and website traffic
+  fingerprinting attacks will become harder, because the adversary can no
+  longer be sure what percentage of the traffic they have seen (depending
+  on their position and other potential concurrent activity).  Similarly,
+  it should also help dampen congestion attacks, since traffic will
+  automatically shift away from a congested guard.
+
+
+
+References:
+
+1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
+2. https://trac.torproject.org/projects/tor/ticket/12206
+3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-node.txt
+4. https://trac.torproject.org/projects/tor/ticket/14917
+5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14
+6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf
+7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt
+8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3
+9. https://tails.boum.org/blueprint/persistent_Tor_state/
+10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3
+11. https://bugs.torproject.org/15060
+12. https://trac.torproject.org/projects/tor/ticket/10969
+13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf
+14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt