[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] prop291: dos2unix the file so we get a Unix format
commit 5e2e04eb9791bb9f92384bcd541de3c1f26dbca8
Author: David Goulet <dgoulet@xxxxxxxxxxxxxx>
Date: Mon Apr 16 11:12:06 2018 -0400
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@xxxxxxxxxxxxxx>
---
proposals/291-two-guard-nodes.txt | 502 +++++++++++++++++++-------------------
1 file 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
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits