commit b98732baef0d3b8383a7f09c7b8d016555bc4d46 Author: Roger Dingledine arma@torproject.org Date: Wed Aug 9 00:20:00 2017 -0400
add another set of documents to 2016-01 trsb case --- htdocs/trsb/2016-01-questionnaire-answers.txt | 113 +++++++++++++++++++++++++ htdocs/trsb/2016-01-questionnaire.txt | 115 ++++++++++++++++++++++++++ htdocs/trsb/2016-01-request.txt | 2 - htdocs/trsb/2016-01-response.txt | 5 +- 4 files changed, 229 insertions(+), 6 deletions(-)
diff --git a/htdocs/trsb/2016-01-questionnaire-answers.txt b/htdocs/trsb/2016-01-questionnaire-answers.txt new file mode 100644 index 0000000..0f1e909 --- /dev/null +++ b/htdocs/trsb/2016-01-questionnaire-answers.txt @@ -0,0 +1,113 @@ + +From: QI ZHONG zhongqi92@berkeley.edu +Date: Mon, 10 Oct 2016 02:34:11 -0700 + +A draft template/questionaire to promote safer Tor experiments + +1a. What are you trying to learn about? Is it: +- New algorithm(s) that enhances current algorithm(s) in Tor. +- New system that interacts with Tor. +- New attack(s) that degrade(s) Tor properties. +- The characteristics of the real-world Tor network and its clients, operators, network topology, etc. +- Something else. + +The characteristics of the real-world Tor network and its clients, operators, network topology, etc. + +1b. What about the above are you trying to learn? Is it: +- Performance enhancement/reduction. +- Security enhancement/reduction. +- Privacy enhancement/reduction. +- Actual real-world trends, details, etc of the Tor network. +-- Could we use this data to construct models about the Tor network? +- Something else. + +Actual real-world trends, details, etc of the Tor network. It might be possible to construct better model. + +1c. Why is it important to learn the above? +- It justifies the new algorithm/system/attack. +- It would reveal (alarming) significant information about the Tor network, and: +-- Tor should change its design (and we have suggestions on how). +-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again). +- Something else. + +Something else. We hope it can make Tor more censorship-resistant. + +2. Could you learn this by doing a closed-form analysis from the design? +- Yes, and it would be pretty close to reality. +- Yes, but it would not be realistic. +-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor. +- No, due to difficulties in performing closed-form analysis from the design. +- No, because it would not be the real-world behavior of the network. + +No, because it would not be the real-world behavior of the network. + +3a. What data points do you need to learn the above? +- How many? +We will be testing the reachability of the default bridges. +- Over what time period and duration? +Indefinite. +- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc). +We test it from off the network. +- What granularity is the data that is collected. +It is only the reachability of different bridges during different time. +- How will they be kept ``safe'' while they are collected and stored? +We don't have any secret data. All our results will be published after our research. +-- Describe what you mean by ``safe'' here. + +3b. How do these data points tell you about the thing you want to learn about? +- Would it be conclusive? +No, but it would give us better insights. +- Would it be valid for only a snap-shot-in time? +Yes. +- Would it have to be updated regularly to remain relevant? +Yes. + +3c. Does the data need to be released to justify your experiments/system? +- Yes. +-- With what granularity would it be reported? +-- Would it be obfuscated in some fashion? +- No. +-- How will you justify your results instead? +Yes. We will obfuscate our probe locations. None of the other data is secret. + +4. Is there an alternative, and existing, source of data you could use instead of collecting your own? +- Yes. +- No, it +-- doesn't exist. +-- is too old. +-- is not released by the collector. +No, it doesn't exist. We can use Tor collector data as supplyment though. + +5. Could you evaluate your enhancement/attack on a (local) test Tor network? +- Yes. +- Yes, but limited by the models we could use. +- No, since the models we have are insufficient, or don't exist, or not robust enough. We need: +-- Realistic client behviour. +-- Realistic networking behaviour. +-- Realistic bandwidth and computation load. +-- Realistic system/Tor interaction. +- No, for another reason. +No. We need a realistic adversary. + +6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network. +6a. When running your experiment on the live-network, you will collect and/or process: +- Only data generated and realted to our own clients and nodes. +- The above as well as those of other users of the Tor network. +- Only data of other users of the Tor network. +Only data generated and realted to our own clients and nodes. + +6b. Will you introduce resources (relays and bandwidth) into the network. +- Yes. +-- We will run clients (honest but curious, and/or malicious). +-- We will run Directories (honest but curious, and/or malicious). +-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious). +- No. +-- How will you observe/influence the network if not directly through Tor nodes? +We will run clients (honest but curious, and/or malicious). + +6c. Will you run custom Tor code on your Tor nodes? +- Yes, but only to log certain events. +- Yes, but it changes the original behavior. +-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact. +No. + diff --git a/htdocs/trsb/2016-01-questionnaire.txt b/htdocs/trsb/2016-01-questionnaire.txt new file mode 100644 index 0000000..7603966 --- /dev/null +++ b/htdocs/trsb/2016-01-questionnaire.txt @@ -0,0 +1,115 @@ + +From: "M. Tariq Elahi" Tariq.Elahi@esat.kuleuven.be +Date: Fri, 30 Sep 2016 14:08:13 +0200 + +Hi David, +Thanks for reaching out about conducting safer experiments on the Tor +network. I am taking the lead to assist you with that. +I have gone over your responses to the guide questions and think you +have done a pretty good job of figuring things out on your own. + +I have created a template (to someday replace the more generic questions +on the webpage) that I am attaching here which is aimed at helping +researchers work through their methodology and aims. Since you have +already provided a lot of the responses, you can ignore those parts of +the document, but do take a look at section 3(a-c), 4, and 6(a-c). It is +more about how you'd do your experiments, store the data you collect, +and keep everything super safe. + +The plan is to take those responses, get together and discuss/clarify +where needed, and then I would write a recommendation for you and the +board to consume stating whether your plan seems plausible. Since this +is our first time and still figuring things out ourselves there is a lot +of flexibility about how we go about this and the end result. Hopefully, +it will be useful for your project, and for the Tor community. + +Look forward to hearing back from you. + +Cheers, +Tariq + +A draft template/questionaire to promote safer Tor experiments + +1a. What are you trying to learn about? Is it: +- New algorithm(s) that enhances current algorithm(s) in Tor. +- New system that interacts with Tor. +- New attack(s) that degrade(s) Tor properties. +- The characteristics of the real-world Tor network and its clients, operators, network topology, etc. +- Something else. + +1b. What about the above are you trying to learn? Is it: +- Performance enhancement/reduction. +- Security enhancement/reduction. +- Privacy enhancement/reduction. +- Actual real-world trends, details, etc of the Tor network. +-- Could we use this data to construct models about the Tor network? +- Something else. + +1c. Why is it important to learn the above? +- It justifies the new algorithm/system/attack. +- It would reveal (alarming) significant information about the Tor network, and: +-- Tor should change its design (and we have suggestions on how). +-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again). +- Something else. + +2. Could you learn this by doing a closed-form analysis from the design? +- Yes, and it would be pretty close to reality. +- Yes, but it would not be realistic. +-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor. +- No, due to difficulties in performing closed-form analysis from the design. +- No, because it would not be the real-world behavior of the network. + +3a. What data points do you need to learn the above? +- How many? +- Over what time period and duration? +- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc). +- What granularity is the data that is collected. +- How will they be kept ``safe'' while they are collected and stored? +-- Describe what you mean by ``safe'' here. + +3b. How do these data points tell you about the thing you want to learn about? +- Would it be conclusive? +- Would it be valid for only a snap-shot-in time? +- Would it have to be updated regularly to remain relevant? + +3c. Does the data need to be released to justify your experiments/system? +- Yes. +-- With what granularity would it be reported? +-- Would it be obfuscated in some fashion? +- No. +-- How will you justify your results instead? + +4. Is there an alternative, and existing, source of data you could use instead of collecting your own? +- Yes. +- No, it +-- doesn't exist. +-- is too old. +-- is not released by the collector. + +5. Could you evaluate your enhancement/attack on a (local) test Tor network? +- Yes. +- Yes, but limited by the models we could use. +- No, since the models we have are insufficient, or don't exist, or not robust enough. We need: +-- Realistic client behviour. +-- Realistic networking behaviour. +-- Realistic bandwidth and computation load. +-- Realistic system/Tor interaction. +- No, for another reason. + +6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network. +6a. When running your experiment on the live-network, you will collect and/or process: +- Only data generated and realted to our own clients and nodes. +- The above as well as those of other users of the Tor network. +- Only data of other users of the Tor network. +6b. Will you introduce resources (relays and bandwidth) into the network. +- Yes. +-- We will run clients (honest but curious, and/or malicious). +-- We will run Directories (honest but curious, and/or malicious). +-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious). +- No. +-- How will you observe/influence the network if not directly through Tor nodes? +6c. Will you run custom Tor code on your Tor nodes? +- Yes, but only to log certain events. +- Yes, but it changes the original behavior. +-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact. + diff --git a/htdocs/trsb/2016-01-request.txt b/htdocs/trsb/2016-01-request.txt index 47e3ff4..3e01adc 100644 --- a/htdocs/trsb/2016-01-request.txt +++ b/htdocs/trsb/2016-01-request.txt @@ -1,8 +1,6 @@
Date: Thu, 18 Aug 2016 10:47:45 -0700 From: David Fifield david@bamsoftware.com -To: Roger Dingledine arma@mit.edu -Cc: Lynn Tsai lynntsai@gmail.com Subject: Tor Research Safety Board: default bridge reachability
We're seeking comments on a continuation of our research on the blocking diff --git a/htdocs/trsb/2016-01-response.txt b/htdocs/trsb/2016-01-response.txt index a77b7a5..e6b4306 100644 --- a/htdocs/trsb/2016-01-response.txt +++ b/htdocs/trsb/2016-01-response.txt @@ -1,10 +1,7 @@
Date: Fri, 16 Dec 2016 16:54:52 +0100 From: "M. Tariq Elahi" Tariq.Elahi@esat.kuleuven.be -To: tor-research-safety@lists.torproject.org, david@bamsoftware.com, - lynntsai@gmail.com, QI ZHONG zhongqi92@berkeley.edu -Subject: Re: [tor-research-safety] (FWD) Tor Research Safety Board: default - bridge reachability +Subject: Re: Tor Research Safety Board: default bridge reachability
Yesterday, I wrote to David et al. with a short summary of our review. The tl;dr was that we (Damon McCoy and I) don't see anything