October 2012 - tor-commits - lists.torproject.org

[torspec/master] Fix margins, reduce duration from 5 days to 3, and mention #7126.
by nickm＠torproject.org 17 Oct '12

17 Oct '12

commit aa85944318fb28bb153373e4f2cf2c174ddd0a1e Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 16 15:35:45 2012 -0700 Fix margins, reduce duration from 5 days to 3, and mention #7126. --- proposals/xxx-using-old-consensus.txt | 91 ++++++++++++++++++++------------- 1 files changed, 55 insertions(+), 36 deletions(-) diff --git a/proposals/xxx-using-old-consensus.txt b/proposals/xxx-using-old-consensus.txt index 6e86406..c0faed2 100644 --- a/proposals/xxx-using-old-consensus.txt +++ b/proposals/xxx-using-old-consensus.txt @@ -8,34 +8,36 @@ Overview This proposal aims to extend the duration that clients will accept old consensus material under conditions where the directory authorities - are either down or fail to produce a valid consensus for an extended period - of time. + are either down or fail to produce a valid consensus for an extended + period of time. Motivation - Currently, if the directory authorities are down or fail to consense for - 24 hours, the entire Tor network will cease to function. Worse, clients - will enter into a state where they all need to re-bootstrap directly - from the directory authorities, which will likely exacerbate any - potential DoS condition that may have triggered the downtime in the first - place. - - The Tor network has had such close calls before. In the past, we've been - able to mobilize a majority of the directory authority operators within this - 24 hour window, but that is only because we've been exceedingly lucky and - the DoS conditions were accidental rather than deliberate. - - If a DoS attack was deliberately timed to coincide with a major US and - European combined holiday such as Christmas Eve, New Years Eve, or Easter, - it is very unlikely we would be able to muster the resources to diagnose - and deploy a fix to the authorities in time to prevent network collapse. + Currently, if the directory authorities are down or fail to consense + for 24 hours, the entire Tor network will cease to function. Worse, + clients will enter into a state where they all need to re-bootstrap + directly from the directory authorities, which will likely exacerbate + any potential DoS condition that may have triggered the downtime in the + first place. + + The Tor network has had such close calls before. In the past, we've + been able to mobilize a majority of the directory authority operators + within this 24 hour window, but that is only because we've been + exceedingly lucky and the DoS conditions were accidental rather than + deliberate. + + If a DoS attack was deliberately timed to coincide with a major US + and European combined holiday such as Christmas Eve, New Years Eve, or + Easter, it is very unlikely we would be able to muster the resources to + diagnose and deploy a fix to the authorities in time to prevent network + collapse. Description - Based on the need to survive multi-day holidays and long weekends balanced - with the need to ensure clients can't be captured on an old consensus - forever, I propose that the consensus liveness constants be set at 5 days - rather than 24 hours. + Based on the need to survive multi-day holidays and long weekends + balanced with the need to ensure clients can't be captured on an old + consensus forever, I propose that the consensus liveness constants be + set at 3 days rather than 24 hours. This requires updating two consensus defines in the source, and one descriptor freshness variable. The descriptor freshness should be @@ -45,25 +47,40 @@ Description Security Concerns: Using an Old Consensus - Clients should not trust old consensus data without an attempt to download - fresher data from a directory mirror. + Clients should not trust old consensus data without an attempt to + download fresher data from a directory mirror. + + As far as I could tell, the code already does this. The minimum + consensus age before we try to download new data is two hours. - As far as I could tell, the code already does this. The minimum consensus - age before we try to download new data is two hours. + However, the ability to accept old consensus documents does introduce + the ability of malicious directory mirrors to feed their favorite old + consensus document to clients to alter their paths until they + download a fresher consensus from elsewhere. Directory guards + (Proposal 207) may exacerbate this ability. + + This proposal does not address such attacks, and seeks only a modest + increase in the valid timespan as a compromise. + + Future consideration of these and other targeted-consensus attacks + will be left to proposals related to ticket #7126[1]. Once those + proposals are complete and implemented, raising the freshness limit + beyond 3 days should be possible. Implementation Notes There appear to be at least three constants in the code involved with - using potentially expired consensus data. Two of them (REASONABLY_LIVE_TIME - and NS_EXPIRY_SLOP) involve the consensus itself, and two - (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with descriptor - liveness. + using potentially expired consensus data. Two of them + (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, + and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with + descriptor liveness. Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH are only used when submitting descriptors for consensus voting. - FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router descriptor - will get before a relay will re-publish. It is set to 18 hours. + FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router + descriptor will get before a relay will re-publish. It is set to 18 + hours. OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE is set at 7 days. @@ -75,11 +92,11 @@ Implementation Notes OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), router_add_to_routerlist(), and client_would_use_router(). - It is my opinion that we should combine REASONABLY_LIVE_TIME and - NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE - a function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: + It is my opinion that we should combine REASONABLY_LIVE_TIME and + NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a + function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: - #define REASONABLY_LIVE_TIME (5*24*60*60) + #define REASONABLY_LIVE_TIME (3*24*60*60) #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME #define OLD_ROUTER_DESC_MAX_AGE \ (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) @@ -87,3 +104,5 @@ Implementation Notes Based on my review of the above code paths, these changes should be all we need to enable clients to use older consensuses for longer while still attempting to fetch new ones. + +1. https://trac.torproject.org/projects/tor/ticket/7126

1 0

[torspec/master] Add proposal to tolerate consensuses older than 24 hours.
by nickm＠torproject.org 17 Oct '12

17 Oct '12

commit 2bcf93d4c72bd9cd52bf1f70a8e1ff49495b19b8 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Oct 1 16:28:56 2012 -0700 Add proposal to tolerate consensuses older than 24 hours. --- proposals/xxx-using-old-consensus.txt | 89 +++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) diff --git a/proposals/xxx-using-old-consensus.txt b/proposals/xxx-using-old-consensus.txt new file mode 100644 index 0000000..50a522d --- /dev/null +++ b/proposals/xxx-using-old-consensus.txt @@ -0,0 +1,89 @@ +Title: Allow use of old consensus material +Author: Mike Perry +Created: 01-10-2012 +Status: Open +Target: 0.2.4.x+ + +Overview + + This proposal aims to extend the duration that clients will accept + old consensus material under conditions where the directory authorities + are either down or fail to produce a valid consensus for an extended period + of time. + +Motivation + + Currently, if the directory authorities are down or fail to consense for + 24 hours, the entire Tor network will cease to function. Worse, clients + will enter into a state where they all need to re-bootstrap directly + from the directory authorities, which will likely exacerbate any + potential DoS condition that may have triggered the downtime in the first + place. + + The Tor network has had such close calls before. In the past, we've been + able to mobilize a majority of the directory authority operators within this + 24 hour window, but that is only because we've been exceedingly lucky and + the DoS conditions were accidental rather than deliberate. + + If a DoS attack was deliberately timed to coincide with a major US and + European combined holiday such as Christmas Eve, New Years Eve, or Easter, + it is very unlikely we would be able to muster the resources to diagnose + and deploy a fix to the authorities in time to prevent network collapse. + +Description + + Based on the need to survive multi-day holidays and long weekends balanced + with the need to ensure clients can't be captured on an old consensus + forever, I propose that the consensus liveness constants be set at 5 days + rather than 24 hours. + + This requires updating two consensus defines in the source, and one + descriptor freshness variable. The descriptor freshness should be + set to a function of the consensus freshness. + + See Implementation Nodes for further details. + +Security Concerns + + Clients should not trust old consensus data without an attempt to download + fresher data from a directory mirror. + + As far as I could tell, the code already does this. The minimum consensus + age before we try to download new data is two hours. + +Implementation Notes + + There appear to be at least three constants in the code involved with + using potentially expired consensus data. Two of them (REASONABLY_LIVE_TIME + and NS_EXPIRY_SLOP) involve the consensus itself, and two + (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with descriptor + liveness. + + Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH + are only used when submitting descriptors for consensus voting. + + FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router descriptor + will get before a relay will re-publish. It is set to 18 hours. + + OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE + is set at 7 days. + + The consensus timestamps are used in + networkstatus_get_reasonably_live_consensus() and + networkstatus_set_current_consensus(). + + OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), + router_add_to_routerlist(), and client_would_use_router(). + + It is my opinion that we should combine REASONABLY_LIVE_TIME and + NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE + a function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: + + #define REASONABLY_LIVE_TIME (5*24*60*60) + #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME + #define OLD_ROUTER_DESC_MAX_AGE \ + (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) + + Based on my review of the above code paths, these changes should be all + we need to enable clients to use older consensuses for longer while + still attempting to fetch new ones.

1 0

[torspec/master] add proposal 212-using-old-consensus
by nickm＠torproject.org 17 Oct '12

17 Oct '12

commit e70357ba5099bded4457b9373ae2120dac651796 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Oct 16 21:58:35 2012 -0400 add proposal 212-using-old-consensus --- proposals/000-index.txt | 2 + proposals/212-using-old-consensus.txt | 109 +++++++++++++++++++++++++++++++++ proposals/xxx-using-old-consensus.txt | 108 -------------------------------- 3 files changed, 111 insertions(+), 108 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2fa2be6..02c88be 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -133,6 +133,7 @@ Proposals by number: 209 Tuning the Parameters for the Path Bias Defense [OPEN] 210 Faster Headless Consensus Bootstrapping [OPEN] 211 Internal Mapaddress for Tor Configuration Testing [OPEN] +212 Increase Acceptable Consensus Age [OPEN] Proposals by status: @@ -182,6 +183,7 @@ Proposals by status: 209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+] 210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+] 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] + 212 Increase Acceptable Consensus Age [for 0.2.4.x+] ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/212-using-old-consensus.txt b/proposals/212-using-old-consensus.txt new file mode 100644 index 0000000..55de290 --- /dev/null +++ b/proposals/212-using-old-consensus.txt @@ -0,0 +1,109 @@ +Filename: 212-using-old-consensus.txt +Title: Increase Acceptable Consensus Age +Author: Mike Perry +Created: 01-10-2012 +Status: Open +Target: 0.2.4.x+ + +Overview + + This proposal aims to extend the duration that clients will accept + old consensus material under conditions where the directory authorities + are either down or fail to produce a valid consensus for an extended + period of time. + +Motivation + + Currently, if the directory authorities are down or fail to consense + for 24 hours, the entire Tor network will cease to function. Worse, + clients will enter into a state where they all need to re-bootstrap + directly from the directory authorities, which will likely exacerbate + any potential DoS condition that may have triggered the downtime in the + first place. + + The Tor network has had such close calls before. In the past, we've + been able to mobilize a majority of the directory authority operators + within this 24 hour window, but that is only because we've been + exceedingly lucky and the DoS conditions were accidental rather than + deliberate. + + If a DoS attack was deliberately timed to coincide with a major US + and European combined holiday such as Christmas Eve, New Years Eve, or + Easter, it is very unlikely we would be able to muster the resources to + diagnose and deploy a fix to the authorities in time to prevent network + collapse. + +Description + + Based on the need to survive multi-day holidays and long weekends + balanced with the need to ensure clients can't be captured on an old + consensus forever, I propose that the consensus liveness constants be + set at 3 days rather than 24 hours. + + This requires updating two consensus defines in the source, and one + descriptor freshness variable. The descriptor freshness should be + set to a function of the consensus freshness. + + See Implementation Notes for further details. + +Security Concerns: Using an Old Consensus + + Clients should not trust old consensus data without an attempt to + download fresher data from a directory mirror. + + As far as I could tell, the code already does this. The minimum + consensus age before we try to download new data is two hours. + + However, the ability to accept old consensus documents does introduce + the ability of malicious directory mirrors to feed their favorite old + consensus document to clients to alter their paths until they + download a fresher consensus from elsewhere. Directory guards + (Proposal 207) may exacerbate this ability. + + This proposal does not address such attacks, and seeks only a modest + increase in the valid timespan as a compromise. + + Future consideration of these and other targeted-consensus attacks + will be left to proposals related to ticket #7126[1]. Once those + proposals are complete and implemented, raising the freshness limit + beyond 3 days should be possible. + +Implementation Notes + + There appear to be at least three constants in the code involved with + using potentially expired consensus data. Two of them + (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, + and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with + descriptor liveness. + + Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH + are only used when submitting descriptors for consensus voting. + + FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router + descriptor will get before a relay will re-publish. It is set to 18 + hours. + + OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE + is set at 7 days. + + The consensus timestamps are used in + networkstatus_get_reasonably_live_consensus() and + networkstatus_set_current_consensus(). + + OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), + router_add_to_routerlist(), and client_would_use_router(). + + It is my opinion that we should combine REASONABLY_LIVE_TIME and + NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a + function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: + + #define REASONABLY_LIVE_TIME (3*24*60*60) + #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME + #define OLD_ROUTER_DESC_MAX_AGE \ + (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) + + Based on my review of the above code paths, these changes should be all + we need to enable clients to use older consensuses for longer while + still attempting to fetch new ones. + +1. https://trac.torproject.org/projects/tor/ticket/7126 diff --git a/proposals/xxx-using-old-consensus.txt b/proposals/xxx-using-old-consensus.txt deleted file mode 100644 index 3e2a57a..0000000 --- a/proposals/xxx-using-old-consensus.txt +++ /dev/null @@ -1,108 +0,0 @@ -Title: Increase Acceptable Consensus Age -Author: Mike Perry -Created: 01-10-2012 -Status: Open -Target: 0.2.4.x+ - -Overview - - This proposal aims to extend the duration that clients will accept - old consensus material under conditions where the directory authorities - are either down or fail to produce a valid consensus for an extended - period of time. - -Motivation - - Currently, if the directory authorities are down or fail to consense - for 24 hours, the entire Tor network will cease to function. Worse, - clients will enter into a state where they all need to re-bootstrap - directly from the directory authorities, which will likely exacerbate - any potential DoS condition that may have triggered the downtime in the - first place. - - The Tor network has had such close calls before. In the past, we've - been able to mobilize a majority of the directory authority operators - within this 24 hour window, but that is only because we've been - exceedingly lucky and the DoS conditions were accidental rather than - deliberate. - - If a DoS attack was deliberately timed to coincide with a major US - and European combined holiday such as Christmas Eve, New Years Eve, or - Easter, it is very unlikely we would be able to muster the resources to - diagnose and deploy a fix to the authorities in time to prevent network - collapse. - -Description - - Based on the need to survive multi-day holidays and long weekends - balanced with the need to ensure clients can't be captured on an old - consensus forever, I propose that the consensus liveness constants be - set at 3 days rather than 24 hours. - - This requires updating two consensus defines in the source, and one - descriptor freshness variable. The descriptor freshness should be - set to a function of the consensus freshness. - - See Implementation Notes for further details. - -Security Concerns: Using an Old Consensus - - Clients should not trust old consensus data without an attempt to - download fresher data from a directory mirror. - - As far as I could tell, the code already does this. The minimum - consensus age before we try to download new data is two hours. - - However, the ability to accept old consensus documents does introduce - the ability of malicious directory mirrors to feed their favorite old - consensus document to clients to alter their paths until they - download a fresher consensus from elsewhere. Directory guards - (Proposal 207) may exacerbate this ability. - - This proposal does not address such attacks, and seeks only a modest - increase in the valid timespan as a compromise. - - Future consideration of these and other targeted-consensus attacks - will be left to proposals related to ticket #7126[1]. Once those - proposals are complete and implemented, raising the freshness limit - beyond 3 days should be possible. - -Implementation Notes - - There appear to be at least three constants in the code involved with - using potentially expired consensus data. Two of them - (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, - and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with - descriptor liveness. - - Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH - are only used when submitting descriptors for consensus voting. - - FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router - descriptor will get before a relay will re-publish. It is set to 18 - hours. - - OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE - is set at 7 days. - - The consensus timestamps are used in - networkstatus_get_reasonably_live_consensus() and - networkstatus_set_current_consensus(). - - OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), - router_add_to_routerlist(), and client_would_use_router(). - - It is my opinion that we should combine REASONABLY_LIVE_TIME and - NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a - function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: - - #define REASONABLY_LIVE_TIME (3*24*60*60) - #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME - #define OLD_ROUTER_DESC_MAX_AGE \ - (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) - - Based on my review of the above code paths, these changes should be all - we need to enable clients to use older consensuses for longer while - still attempting to fetch new ones. - -1. https://trac.torproject.org/projects/tor/ticket/7126

1 0

[torspec/master] Merge remote-tracking branch 'mikeperry/tolerate-old-consensus'
by nickm＠torproject.org 17 Oct '12

17 Oct '12

commit 65a25edba1d16d2d651bcf02e516171813302d96 Merge: d312aa6 e4a4d50 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Oct 16 21:56:52 2012 -0400 Merge remote-tracking branch 'mikeperry/tolerate-old-consensus' proposals/xxx-using-old-consensus.txt | 108 +++++++++++++++++++++++++++++++++ 1 files changed, 108 insertions(+), 0 deletions(-)

1 0

[torspec/master] Retitle.
by nickm＠torproject.org 17 Oct '12

17 Oct '12

commit e4a4d50d35f04a44f0e0d5bf6c478cf83474ff75 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 16 15:38:22 2012 -0700 Retitle. --- proposals/xxx-using-old-consensus.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/proposals/xxx-using-old-consensus.txt b/proposals/xxx-using-old-consensus.txt index c0faed2..3e2a57a 100644 --- a/proposals/xxx-using-old-consensus.txt +++ b/proposals/xxx-using-old-consensus.txt @@ -1,4 +1,4 @@ -Title: Allow use of old consensus material +Title: Increase Acceptable Consensus Age Author: Mike Perry Created: 01-10-2012 Status: Open

1 0

[torspec/master] Proposal 209: Fix a math error wrt malicious failure rates.
by nickm＠torproject.org 16 Oct '12

16 Oct '12

commit d312aa6609bd5ee3c1026538c6b7fa2dd99e02a5 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 16 13:45:02 2012 -0700 Proposal 209: Fix a math error wrt malicious failure rates. Forgot I needed to compute failure rates *given* an evil Guard. --- proposals/209-path-bias-tuning.txt | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/proposals/209-path-bias-tuning.txt b/proposals/209-path-bias-tuning.txt index a1bf493..25ee9de 100644 --- a/proposals/209-path-bias-tuning.txt +++ b/proposals/209-path-bias-tuning.txt @@ -30,13 +30,13 @@ Motivation connections, breaking the O((c/n)^2) property of Tor's original threat model. - In this case, however, the adversary is only carrying circuits - for which either the entry and exit are compromised, or all - three nodes are compromised. This means that the adversary fails - all but (c/n)^2 + (c/n)^3 of their circuits. For 20% c/n compromise, - such an adversary would only succeed 4.8% of their circuit attempts. - For 33% c/n compromise, such an adversary would still only succeed - 11.7% of their circuits. + In this case, however, the adversary is only carrying circuits for + which either the entry and exit are compromised, or all three nodes are + compromised. This means that the adversary's Guards will fail all but + (c/n) + (c/n)^2 of their circuits for clients that select it. For 10% + c/n compromise, such an adversary succeeds only 11% of their circuits + that start at their compromised Guards. For 20% c/n compromise, such + an adversary would only succeed 24% of their circuit attempts. It is this property which leads me to believe that a simple local accounting defense is indeed possible and worthwhile. @@ -201,11 +201,13 @@ Security Considerations: Targeted Failure Attacks Since both conditions would elicit notices and/or warns from all clients, this attack should be detectable. It can also be detected - through the bandwidth authorities, should we deploy #7023. + through the bandwidth authorities (who could possibly even + set pathbias parameters directly based on measured ambient circuit + failure rates), should we deploy #7023. - We could also conceivably lower pb_disablepct from 30 as a + We could also conceivably lower pb_disablepct to 25% as a potential mitigation, based on the fact that a 20% c/n adversary - would only carry 5% of their circuits in the extreme case. + would only carry 24% of their circuits in the extreme case. Implementation Notes: Log Messages

1 0

[torspec/master] Update Prop209 based on questions+comments from reviewers.
by nickm＠torproject.org 16 Oct '12

16 Oct '12

commit 67866b0df1561e139e69f5348b7db559fa3cca40 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 16 13:15:13 2012 -0700 Update Prop209 based on questions+comments from reviewers. Added an analysis of targeted failure attacks, and clarified some design properties. Also added a section that describes how the proposal differs from what is currently implemented in origin/master. --- proposals/209-path-bias-tuning.txt | 100 +++++++++++++++++++++++++++++++----- 1 files changed, 87 insertions(+), 13 deletions(-) diff --git a/proposals/209-path-bias-tuning.txt b/proposals/209-path-bias-tuning.txt index 004729e..a1bf493 100644 --- a/proposals/209-path-bias-tuning.txt +++ b/proposals/209-path-bias-tuning.txt @@ -16,10 +16,10 @@ Overview Motivation - The Path Bias defense is designed to defend against a type of route capture - where malicious Guard nodes deliberately fail circuits that extend to - non-colluding Exit nodes to maximize their network utilization in favor of - carrying only compromised traffic. + The Path Bias defense is designed to defend against a type of route + capture where malicious Guard nodes deliberately fail circuits that + extend to non-colluding Exit nodes to maximize their network + utilization in favor of carrying only compromised traffic. This attack was explored in the academic literature in [1], and a variant involving cryptographic tagging was posted to tor-dev[2] in @@ -30,6 +30,17 @@ Motivation connections, breaking the O((c/n)^2) property of Tor's original threat model. + In this case, however, the adversary is only carrying circuits + for which either the entry and exit are compromised, or all + three nodes are compromised. This means that the adversary fails + all but (c/n)^2 + (c/n)^3 of their circuits. For 20% c/n compromise, + such an adversary would only succeed 4.8% of their circuit attempts. + For 33% c/n compromise, such an adversary would still only succeed + 11.7% of their circuits. + + It is this property which leads me to believe that a simple local + accounting defense is indeed possible and worthwhile. + Design Description The Path Bias defense is a client-side accounting mechanism in Tor that @@ -45,14 +56,23 @@ Design Description falls below 70%, a warn when Guard success rate falls below 50%, and should drop the Guard when the success rate falls below 30%. + Circuit build timeouts are only counted as path failures if the + circuit fails to complete before the 95% "right-censored" (aka + "MEASUREMENT_EXPIRED") timeout interval, not the 80% timeout + condition. See 2.4.1 of path-spec for further details on circuit + timeout calculations. + To ensure correctness, checks are performed to ensure that - we do not count successes without also counting the first hop. + we do not count successes without also counting the first hop (see + usage of path_state_t as well as pathbias_* in the source). Similarly, to provide a moving average of recent Guard activity while - still preserving the ability to ensure correctness, we "scale" the - success counts by an integer divisor (currently 2) when the counts - exceed the moving average window (300) and when the division - does not produce integer truncation. + still preserving the ability to ensure correctness, we periodically + "scale" the success counts by first multiplying by a numerator + (currently 1) and then dividing by an integer divisor (currently 2). + + Scaling is performed when when the counts exceed the moving average + window (300) and when the division does not produce integer truncation. No log messages should be displayed, nor should any Guard be dropped until it has completed at least 150 first hops (inclusive). @@ -79,9 +99,9 @@ Analysis: Simulation The spread between the cutoff values and the normal rate of circuit success has a substantial effect on false positives. From the - simulation's results, the sweet spot for the size of this spread appears - to be 10%. In other words, we want to set the cutoffs such that they are - 10% below the success rate we expect to see in normal usage. + simulation's results, the sweet spot for the size of this spread + appears to be 10%. In other words, we want to set the cutoffs such that + they are 10% below the success rate we expect to see in normal usage. The simulation also demonstrates that larger "scaling window" sizes reduce false positives for instances where non-malicious guards @@ -101,6 +121,9 @@ Analysis: Live Scan Based on these results, the notice condition should be 70%, the warn condition should be 50%, and the drop condition should be 30%. + However, see the Security Considerations sections for reasons + to choose more lenient bounds. + Future Analysis: Deployed Clients It's my belief that further analysis should be done by deploying @@ -113,7 +136,7 @@ Future Analysis: Deployed Clients so that we have enough data to consider deploying the Guard-dropping cutoff in 0.2.4.x. -Security Considerations +Security Considerations: DoS Conditions While the scaling window does provide freshness and can help mitigate "bait-and-switch" attacks, it also creates the possibility of conditions @@ -151,6 +174,39 @@ Security Considerations the (c/n)^2 * 100/CUTOFF_PERCENT limit in aggregate), so we do have to find balance between these concerns. +Security Considerations: Targeted Failure Attacks + + If an adversary controls a significant portion of the network, they + may be able to target a Guard node by failing their circuits. In the + context of cryptographic tagging, both the Middle node and the Exit + node are able to recognize their colluding peers. The Middle node sees + the Guard directly, and the Exit node simply reverses a non-existent + tag, causing a failure. + + P(EvilMiddle) || P(EvilExit) = 1.0 - P(HonestMiddle) && P(HonestExit) + = 1.0 - (1.0-(c/n))*(1.0-(c/n)) + + For 10% compromise, this works out to the ability to fail an + additional 19% of honest Guard circuits, and for 20% compromise, + it works out to 36%. + + When added to the ambient circuit failure rates (10-20%), this is + within range of the notice and warn conditions, but not the guard + failure condition. + + However, this attack does become feasible if a network-wide DoS + (or simply CPU load) is able to elevate the ambient failure + rate to 51% for the 10% compromise case, or 34% for the 20% + compromise case. + + Since both conditions would elicit notices and/or warns from all + clients, this attack should be detectable. It can also be detected + through the bandwidth authorities, should we deploy #7023. + + We could also conceivably lower pb_disablepct from 30 as a + potential mitigation, based on the fact that a 20% c/n adversary + would only carry 5% of their circuits in the extreme case. + Implementation Notes: Log Messages Log messages need to be chosen with care to avoid alarming users. @@ -190,9 +246,27 @@ Implementation Notes: Consensus Parameters pb_scalecircs=300 The number of first hops at which we scale the counts down. + pb_multfactor=1 + The integer numerator by which we scale. + pb_scalefactor=2 The integer divisor by which we scale. + pb_dropguards=0 + If non-zero, we should actually drop guards as opposed to warning. + +Implementation Notes: Differences between this proposal and source + + This proposal adds a few changes over the implementation currently + deployed in origin/master. + + The log messages suggested above are different than those in the + source. + + Also, the following consensus parameters are additions: + pb_multfactor + pb_warnpct + pb_dropguards 1. http://freehaven.net/anonbib/cache/ccs07-doa.pdf

1 0

r25848: {website} fix an erroroneous space in the url for dwolla. (website/trunk/donate/en)
by Andrew Lewman 16 Oct '12

16 Oct '12

Author: phobos Date: 2012-10-16 20:22:38 +0000 (Tue, 16 Oct 2012) New Revision: 25848 Modified: website/trunk/donate/en/donate.wml Log: fix an erroroneous space in the url for dwolla. Modified: website/trunk/donate/en/donate.wml =================================================================== --- website/trunk/donate/en/donate.wml 2012-10-16 20:04:32 UTC (rev 25847) +++ website/trunk/donate/en/donate.wml 2012-10-16 20:22:38 UTC (rev 25848) @@ -161,7 +161,7 @@ <p>Dwolla is a peer to peer payment platform which allows users to exchange money quickly, safely, at a lower cost.</p> <p style="text-align:center;"><strong><a -href="https://www.dwolla.com/hub/ thetorproject">Continue to Dwolla +href="https://www.dwolla.com/hub/thetorproject">Continue to Dwolla »</a></strong></p> </div>

1 0

r25847: {website} add dwolla donation option. (in website/trunk: css donate/en)
by Andrew Lewman 16 Oct '12

16 Oct '12

Author: phobos Date: 2012-10-16 20:04:32 +0000 (Tue, 16 Oct 2012) New Revision: 25847 Modified: website/trunk/css/layout.css website/trunk/donate/en/donate.wml Log: add dwolla donation option. Modified: website/trunk/css/layout.css =================================================================== --- website/trunk/css/layout.css 2012-10-15 16:49:21 UTC (rev 25846) +++ website/trunk/css/layout.css 2012-10-16 20:04:32 UTC (rev 25847) @@ -1212,6 +1212,13 @@ line-height: 13px; } + dwolla p { + text-align: justify; + margin-top: 10px; + font-size: 11px; + line-height: 13px; + } + /* Project page */ Modified: website/trunk/donate/en/donate.wml =================================================================== --- website/trunk/donate/en/donate.wml 2012-10-15 16:49:21 UTC (rev 25846) +++ website/trunk/donate/en/donate.wml 2012-10-16 20:04:32 UTC (rev 25847) @@ -22,6 +22,7 @@ <ul class="hlist"> <li><a href="#paypal">Paypal</a></li> <li><a href="#amazon">Amazon Payments</a></li> + <li><a href="#dwolla">Dwolla</a></li> <li><a href="#givv">Givv.org</a></li> <li><a href="#cash">checks, money orders, bank transfers, stock grants, or other more sophisticated transactions</a></li> @@ -153,6 +154,17 @@ <small>Requires an Amazon Account</small> </div>  + + <a id="dwolla"></a> + <div class="dbox dsmall dwolla"> + <h3>Donate via Dwolla</h3> + <p>Dwolla is a peer to peer payment platform which allows users to +exchange money quickly, safely, at a lower cost.</p> + <p style="text-align:center;"><strong><a +href="https://www.dwolla.com/hub/ thetorproject">Continue to Dwolla +»</a></strong></p> + </div> +  <a id="givv"></a> <div class="dbox dsmall givv">

1 0

[translation/liveusb-creator] Update translations for liveusb-creator
by translation＠torproject.org 16 Oct '12

16 Oct '12

commit 6e9d6a8426956441ca27449c1fa6f242d95b7f97 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Oct 16 19:15:34 2012 +0000 Update translations for liveusb-creator --- sk/sk.po | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/sk/sk.po b/sk/sk.po index 5f7eeb1..e1c262f 100644 --- a/sk/sk.po +++ b/sk/sk.po @@ -3,14 +3,15 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# <koloman375(a)gmail.com>, 2012. # Ondrej Šulek <feonsu(a)gmail.com>, 2008-2009. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2012-04-13 14:16+0200\n" -"PO-Revision-Date: 2012-10-03 18:10+0000\n" -"Last-Translator: Tor Project <tor-assistants(a)torproject.org>\n" +"PO-Revision-Date: 2012-10-16 18:56+0000\n" +"Last-Translator: K0L0M4N <koloman375(a)gmail.com>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -31,7 +32,7 @@ msgstr "Sťahujem %s..." #: ../liveusb/gui.py:197 #, python-format msgid "Device is too small: it must be at least %s MiB." -msgstr "" +msgstr "Zariadenie je príliš malé: musí mať aspoň %s MiB" #: ../liveusb/gui.py:226 msgid "" @@ -42,7 +43,7 @@ msgstr "Chyba: Nie je možné nastaviť menovka alebo získať UUID vašeho zari #: ../liveusb/gui.py:276 #, python-format msgid "Installation complete! (%s)" -msgstr "" +msgstr "Inštalácia je dokončená! (%s)" #: ../liveusb/gui.py:281 msgid "LiveUSB creation failed!" @@ -119,12 +120,12 @@ msgstr "" msgid "" "Your device already contains a LiveOS.\n" "If you continue, this will be overwritten." -msgstr "Vaše zariadenie už obsahuje LiveOS.\nPri pokračovaní, bude prepísaný." +msgstr "Vaše zariadenie už obsahuje LiveOS.\nAk budete pokračovať, bude prepísaný." #: ../liveusb/gui.py:661 msgid "" "Warning: Creating a new persistent overlay will delete your existing one." -msgstr "Upozornenie: vytvorením nového trvalého úložiska sa zmaže už existujúce." +msgstr "Upozornenie: Vytvorením nového trvalého úložiska sa vymaže už existujúce." #: ../liveusb/gui.py:717 msgid "Download complete!" @@ -132,11 +133,11 @@ msgstr "Sťahovanie dokončené!" #: ../liveusb/gui.py:721 msgid "Download failed: " -msgstr "Sťahovanie zlyhalo: " +msgstr "Sťahovanie zlyhalo: " #: ../liveusb/gui.py:722 msgid "You can try again to resume your download" -msgstr "Skúste znovu spustiť sťahovanie" +msgstr "Môžete skúsiť znovu spustiť sťahovanie" #: ../liveusb/gui.py:728 msgid "Select Live ISO" @@ -170,7 +171,7 @@ msgstr "" #: ../liveusb/creator.py:132 msgid "Verifying ISO MD5 checksum" -msgstr "Overuje sa ISO kontrolný súčet MD5" +msgstr "Overuje sa kontrolný súčet ISO MD5" #: ../liveusb/creator.py:137 msgid "ISO MD5 checksum verification failed"

1 0