August 2017 - tor-commits - lists.torproject.org

[research-web/master] two of the projects with public web pages now
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 088ae39389fa77a5f65c71e69d0c68bea192d0f3 Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:55:19 2017 -0400 two of the projects with public web pages now --- htdocs/safetyboard.html | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/htdocs/safetyboard.html b/htdocs/safetyboard.html index 79c833c..76a4b48 100644 --- a/htdocs/safetyboard.html +++ b/htdocs/safetyboard.html @@ -191,11 +191,15 @@ public first. <ul> <li><a href="trsb/2017-02-request.txt">request</a> <li><a href="trsb/2017-02-response.txt">response</a> +<li><a href="http://tor.ccs.neu.edu/">research project page</a> </ul> 2017-03: [still anonymized during paper review] +<ul> +<li><a href="https://onionpop.github.io/">research project page</a> +</ul> <hr> <a id="who"></a>

1 0

[research-web/master] be more assertive that there really is a board
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 9d66e8f563130fe8ab0ca62da0beb84947336ead Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:52:56 2017 -0400 be more assertive that there really is a board --- htdocs/safetyboard.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/htdocs/safetyboard.html b/htdocs/safetyboard.html index c13f0a3..79c833c 100644 --- a/htdocs/safetyboard.html +++ b/htdocs/safetyboard.html @@ -203,12 +203,11 @@ public first. -The current people who have expressed interest in the board are: +The current members of the board are: <ul> <li>George Danezis <li>Roger Dingledine <li>Tariq Elahi -<li>Bryan Ford <li>Ian Goldberg <li>Rob Jansen <li>Aaron Johnson

1 0

[research-web/master] pointers to the currently published case documents
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 33b736eea79925caa027b8d446e443a5f5af9c8d Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:50:04 2017 -0400 pointers to the currently published case documents --- htdocs/safetyboard.html | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/htdocs/safetyboard.html b/htdocs/safetyboard.html index dd05f86..c13f0a3 100644 --- a/htdocs/safetyboard.html +++ b/htdocs/safetyboard.html @@ -155,7 +155,47 @@ list at lists.torproject.org, and also let one of us know that you did. -This is where the templates and example self-assessments will go. +We are publishing safety board cases in this section, to help you +craft your own submission. Note that some cases are still private, for +example because the researchers are waiting for their paper to become +public first. + + + + +2016-01: +<ul> +<li><a href="trsb/2016-01-request.txt">request</a> +<li><a href="trsb/2016-01-questionnaire.txt">questionnaire</a> +<li><a href="trsb/2016-01-questionnaire-answers.txt">questionnaire answers</a> +<li><a href="trsb/2016-01-response.txt">response</a> +</ul> + + +2016-02: +[still anonymized during paper review] + + +2016-03: +<ul> +<li><a href="trsb/2016-03-request.txt">request</a> +<li><a href="trsb/2016-03-response.txt">response</a> +</ul> + + +2017-01: +[still anonymized during paper review] + + +2017-02: +<ul> +<li><a href="trsb/2017-02-request.txt">request</a> +<li><a href="trsb/2017-02-response.txt">response</a> +</ul> + + +2017-03: +[still anonymized during paper review] <hr> <a id="who"></a>

1 0

[research-web/master] make it look more inviting to submit
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 6c7c28b14461a12cffcd62b8f91ea483d9193590 Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:35:28 2017 -0400 make it look more inviting to submit --- htdocs/safetyboard.html | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/htdocs/safetyboard.html b/htdocs/safetyboard.html index 279eac1..dd05f86 100644 --- a/htdocs/safetyboard.html +++ b/htdocs/safetyboard.html @@ -144,8 +144,10 @@ In the future, we'd like to come up with a more thorough template for self-assessments, to help you make sure you don't miss any critical areas. Please let us know what would help you most. -Contact address coming soon. In the meantime, mailing Roger is not -a terrible plan. +We're looking into setting up reviewing software to be +better organized, but in the meantime the best option is to mail the <a +href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-research-safety">tor-research-safety</a> +list at lists.torproject.org, and also let one of us know that you did. <hr> <a id="examples"></a>

1 0

[research-web/master] add files for 2017-02 trsb case
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 7cb518589a55a570d2afe91e9fbc3285cf691e44 Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:22:31 2017 -0400 add files for 2017-02 trsb case --- htdocs/trsb/2017-02-request.pdf | Bin 0 -> 46014 bytes htdocs/trsb/2017-02-request.txt | 15 +++ htdocs/trsb/2017-02-response.txt | 192 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 207 insertions(+) diff --git a/htdocs/trsb/2017-02-request.pdf b/htdocs/trsb/2017-02-request.pdf new file mode 100644 index 0000000..706ed20 Binary files /dev/null and b/htdocs/trsb/2017-02-request.pdf differ diff --git a/htdocs/trsb/2017-02-request.txt b/htdocs/trsb/2017-02-request.txt new file mode 100644 index 0000000..a18a00f --- /dev/null +++ b/htdocs/trsb/2017-02-request.txt @@ -0,0 +1,15 @@ +Date: Thu, 11 May 2017 03:18:19 -0400 (EDT) +From: Guevara Noubir <noubir(a)ccs.neu.edu> +Subject: Privacy-Preserving Longevity Study of Hidden Services + +Dear Tor Safety Board members, + +We have a collaboration between three teams, Erik Blass (Airbus), +Aziz Mohaisen (University of Buffalo), Guevara Noubir (Northeastern +University), and have been working on the design of a privacy-preserving +study of the lifespan of hidden services. Please find attached our +proposed design. We look forward to your feedback. + +Best regards, +Guevara + diff --git a/htdocs/trsb/2017-02-response.txt b/htdocs/trsb/2017-02-response.txt new file mode 100644 index 0000000..e485755 --- /dev/null +++ b/htdocs/trsb/2017-02-response.txt @@ -0,0 +1,192 @@ +Date: Tue, 20 Jun 2017 04:12:52 -0400 +From: Roger Dingledine <arma(a)mit.edu> +Subject: Re: Privacy-Preserving Longevity Study of Hidden Services + +--- My first thoughts --- + +Initial thoughts on angles to consider: + +A) The traditional question for this group: Is their methodology safe +enough? Do they provide enough detail and specificity for us to decide +whether it's safe? + +B) Assuming yes, do we have faith that they can build and implement +and deploy the thing they describe? + +This piece is interesting, because the bad-relays team already identified +and kicked out their relays from the network, since they looked like +an unidentified Sybil attack (and then Donncha contacted them, since +some of the relays were from neu, and then a few days later they sent +us this pdf). + +I think ultimately they should get the bad-relays team to be comfortable +with the plan (else the bad-relays team will quite reasonably wonder +what the next Sybil attack is for, and try to disrupt it). And I think +we here can play a big role in either reassuring the bad-relays team or +not doing that. + +C) What other steps should they take when deploying their experimental +relays, like labelling their relay nicknames, setting contactinfo, +setting myfamily, etc? Maybe there's a set of best practices we can +invent and then recommend. + +We might also choose to recommend that they go public about the +experiment, before they do it -- unless they have a compelling need for +secrecy, e.g. because it would mess up the experiment, and I don't see +one here? + +D) Do we think their mechanism is measuring things correctly, and +measuring the right things? + +That is, if they collect things and compute them as they describe, +will they indeed get the results they think they'll get? Part A is +"is it safe to do", and part D is "will it actually work". + +E) Is it worthwhile, that is, how valuable are the outcomes they're +aiming for? + +That is, what do we think about the risk (A) vs the accuracy (D) vs the +benefit (E)? + +E) They seem to have some weird assumptions in their hypothesis, +e.g. "Short-lived hidden services could indicate not to be legitimate +domains, as compared to long-lived domains." Many short-lived services +could be things other websites, such as onionshare addresses. The HSDirs +can't distinguish what protocol the onion service speaks. These sorts +of issues aren't killers, but it would be polite of us to point them +out while we're noticing them. + +F) What do I leave out? + +And finally, I'll note that this submission has a lot of overlap with +what I would expect to see in a hypothetical future Privcount submission, +so here we are with a chance to set the precedent well. :) + +--- Anonymous reviewer 2 --- + +Motivation +- Why would short-lived hidden services denote illegitimate domains? Onion +share and Ricochet are legitimate applications that likely have +short-lived hidden services. +- How would an unusual lifetime identify a hidden service? + +Data Collection +- The protocol isn't active secure. For example, consider a malicious +HSDir or client that "marks" each hash-table entry by adding in some +value that is a unique multiple of a base value larger than the largest +expected count. Other well-known active attacks can be used as well. +- Malicious inputs can arbitrarily increase the counts. +- How many parties are controlling the HSDirs? Three? +- Are the HSDirs running as normal? Will they run only for the lifetime +of the study or are they more stable? How many HSDirs will be controlled +by any one entity? +- Can the output be made noisy? The data has the flavor of "anonymized" +data, which can frequently be deanonymized by an adversary with auxiliary +information. +- For how long will measurement occur before aggregation? +- Who is in control of the measurement study? Can that entity set +the measurement interval arbitrarily short (thus eliminating any +aggregation over time) or otherwise change the measurement parameters +to defeat privacy protections (e.g. by modifying the key/identities of +the participants)? +- Will the protocol implementation be made publicly available? Will it +receive any scrutiny outside of the implementor(s)? + +Overall, the risk seems minimal against the most likely threats (passive +observation, post-hoc compulsion). Reasonable steps are taken to secure +individual and intermediate data, and the output should be aggregated to +a fairly high degree. However, I do worry that this is a bit of security +theater, as it doesn't seem unlikely that the measurement will suffer +from easily exploitable weaknesses that eliminate its purported security +properties, such as + 1. Control of crucial measurement parameters by a single entity + 2. Active attacks that can be easily run by any single party, *including + malicious clients* + 3. Common implementation oversights/shortcuts (e.g. not using/verifying + long-term public keys, use of an insecure broadcast protocol, using + a language such as Python that doesn't support secure deletion of keys) + +I do also worry about the validity of claims that can be made from +this measurement study. How big is the hash table? If there are lots +of collisions, then the apparent lifetimes will actually be the sum of +lifetimes of many colliding services. You should be able to bound the +chance that this case occurs or detect when it does. Also, it seems as if +the protocol couldn't tell the difference between an onion service that +frequently publishes its descriptor (e.g. due to frequently-changing +Introduction Points) and one that is around for a long time. Those are +very different cases. + +--- Anonymous Reviewer 3 --- + +Recommendations: + +Correctly marking relays as family, adding contact info, a public page +describing the study and research protocol and linking it in the contact +info for the relays. + +Question of sniffing onions for discovery versus using other discovery +methods. This is a question of how much is gained by measuring "private +onion sites" versus only measuring "public onion sites"? Limiting to +public onions without sniffing can be done as in prior work: +http://s3.eurecom.fr/docs/www17_darktracing.pdf + +--- My meta-review putting the above together --- + +I think the discussion comes down to three points for analysis: + +(A) Is your plan more dangerous than you think? That is, did we find +new risks in the proposed protocol / methodology? + +Reviewer 2 identified some issues where a malicious component of your +system, e.g. one of the relays, or any client, could influence the +resulting data. They also suggested adding noise into the aggregated +output. These sound like good points, either for modifying the protocol +before you do the experiment, or at least for acknowledging in the +paper. Having good answers to Reviewer 2's methodology clarifying +questions seems smart, especially for item (C) below. + +Overall, the consensus is that it's pretty low risk: the safety board +people are ok with the research, especially once you've thought through +the analysis from Reviewer 2. + +(B) Are you on track to being able to answer your research questions, +if you do the proposed experiments? + +This one is trickier. I think there are real concerns about whether you +would be able to answer your research questions as currently posed -- +short lived onion services could be Onionshare users, Ricochet users, +or something else. It's a poor assumption that they're all websites, +and it gets especially poor when you're grabbing them at the HSDirs +because nobody knows even what fraction of onion services are websites +or Ricochet or whatever. + +I think you should rethink whether you'll be able to answer your research +questions this way, because I suspect you won't. That said, ultimately +this is a safety board, so technically our perspectives on this part +are out of scope and you don't need to care about them. :) + +(C) What are our recommendations for how to best deploy these relays in +the real Tor network while keeping the network operators happy? + +I think Reviewer 3's recommendations here are a great start: set your +MyFamily lines correctly -- one family for all three research groups +-- and set each ContactInfo accurately too, and include a url in the +ContactInfo to a page that describes who you are, what you're doing, +why it's useful, and why your methodology is as safe as you can make it. + +The reason it's not workable to convince only the directory authority +operators in private is that there's a community of people on the +tor-relays list who are hunting for Sybils and other anomalies, and +there's a good chance they will find your relay family after a while, +and I expect the directory authority operators won't want to be in +the position then of saying "yes, we know about this, but don't worry, +you don't need to know." + +All of this said, assuming you want to proceed, I will volunteer to be +the mediator to explain to the other directory authority operators why +your plan seems to be a safe enough plan. I can't speak for all of them +or predict what they'll want to learn, but I'm optimistic we'd be able +to find some way forward. + +--Roger +

1 0

[research-web/master] add files for 2016-03 trsb case
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit 00053b5515a1364b0741a510afaaf675b0b37b5d Author: Roger Dingledine <arma(a)torproject.org> Date: Wed Aug 9 00:21:34 2017 -0400 add files for 2016-03 trsb case --- htdocs/trsb/2016-03-request.txt | 67 +++++++++++++ htdocs/trsb/2016-03-response.txt | 201 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 268 insertions(+) diff --git a/htdocs/trsb/2016-03-request.txt b/htdocs/trsb/2016-03-request.txt new file mode 100644 index 0000000..3c8b1f7 --- /dev/null +++ b/htdocs/trsb/2016-03-request.txt @@ -0,0 +1,67 @@ +Date: Wed, 26 Oct 2016 19:10:45 -0400 +From: Kymberlee McMaster <kymberlee.mcmaster(a)gmail.com> +Subject: Re: Tor Research Safety Board + +Please see below for our answers to the questions on the website. + + - What are you trying to learn, and why is that useful for the world? + That is, what are the hoped-for benefits of your experiment? + - Team DIRE plans to analyze major events relating to the Dark Internet + and the substituent community response, the culture of the Dark Internet + community, and bitcoin's use as a form of currency in Dark Internet + marketplaces. The communication of a community during and after events can + provide insight into the culture of the people immersed in that community. + In order to understand the culture found on Dark Internet marketplaces, + Team DIRE plans to study the communication among individuals within the + Dark Internet community during events, such as the shutdown of a popular + marketplace. + - Our goal is to answer the following question: How does the + communities response to major events reflect the underlying culture? We + hypothesize that, although members of the Dark Internet are anonymous, + these events will bring the community together and give a representation of + the Dark Internet's culture that is different from the day to day. It is + useful for the world to understand the culture of the Dark Internet as it + expands its reach and is used by more and more people. + - What exactly is your plan? That is, what are the steps of your + experiment, what will you collect, how will you keep it safe, and so on. + - Our plan is twofold. We plan to collect texts form sources such as + blogs, Reddit, and news websites that all discuss the Dark Internet so we + can analyze their view of the Dark Internet. We then plan to take this + analysis and compare it to some events that have occurred involving the + Dark net to see if their view or user reactions change during those times + of crisis. All texts being used are public information available to anyone + with access to the Internet. Each text is coded so that we only use the + coded values in our analysis of those texts. We also plan to purchase items + from both Dark net and traditional Internet marketplaces and compare the + experiences involved with both and the quality of the products received in + relation to the price of the product. + - What attacks or risks might be introduced or assisted because of your + actions or your data sets, and how well do you resolve each of them? Use + the "safety guidelines" above to help in the brainstorming and analysis. + - Our data sets will be limited to the coding of the articles that we + read that have been published for public view on the Internet and Dark + Internet as well as the products that we receive from the purchasing we are + going through. Due to the nature of our project and the fact that we are + only looking to compare the views and products of the marketplaces on the + Dark and traditional Internet, there will be no attacks or risks to Tor due + to our actions and data sets. + - Walk us through why the benefits from item 1 outweigh the remaining + risks from item 3: why is this plan worthwhile despite the remaining risks + - Since we believe there are no risks associated with the conduction of + this study, the benefits of learning about the differences in the way Dark + and traditional Internet marketplaces behave and are viewed can only + provide valuable insight into their cultures. + +Please let me know if you have any questions or need further information on +the above information. We tried to keep it short but also descriptive +enough that you would understand what we were trying to do without bogging +you down with the exact things we are coding in our textual analysis. + +Additionally, my team will need to present our thesis next semester to a +panel of experts, and we were wondering if you would be interested in +serving as a member of the panel. + +Thank you for all of your help with our team! + +-Kym + diff --git a/htdocs/trsb/2016-03-response.txt b/htdocs/trsb/2016-03-response.txt new file mode 100644 index 0000000..8dbf64d --- /dev/null +++ b/htdocs/trsb/2016-03-response.txt @@ -0,0 +1,201 @@ +Date: Thu, 22 Dec 2016 01:07:53 -0500 +From: Paul Syverson <paul.syverson(a)nrl.navy.mil> +Subject: Re: Tor Research Safety Board + +Hi Kymberlee, + +Here is the TRSB response to your proposal. +Please share with your team. + +May the season make sense to you and yours, +Paul + +---------------------------------------- + +Dear UMD Gemstone Team DIRE, + +Thank you for your submission of proposed research to the Tor Research +Safety Board. Your proposal was reviewed by three members of the +Board. I have assembled this response from the reviews each has +given. There was no significant discussion since reviews were largely +in agreement. + +Aside from safety considerations, all reviewers noted that they found +the research to be potentially quite interesting. That is not always +so, even for seasoned researchers much less undergraduates. Thus +congratulations already in that respect. + +All reviewers agreed that there are no Tor-specific safety concerns +for your research project. Nonetheless, all noted similar concerns +for such research on the Internet, whether concerning Tor or not. + +Details can be found in the comments of each reviewer, included below. +But in summary the concerns are + +1. Make sure that you take adequate security precautions for yourselves +not just those you research. + +2. Be aware that when coding input from multiple sources, potential +exists for privacy or safety risks to emerge out of the synthesis, +even if the individual items being coded are safe in isolation. + +3. What constitutes "public" information may not be black-and-white and +can have lots of context to it. + +Any or all of these may require the input or analysis of your IRB. In +any case you should look over our comments and make sure that you are +both taking them into consideration yourselves and making appropriate +decisions with respect to your IRB. + +Please let me know if you have any further questions or comments. +I look forward to seeing how your work progresses. + +Sincerely, +Paul Syverson + +--------------------------------------------------------------- +Comments from Reviewer A +--------------------------------------------------------------- +Based on the answers to the questionnaire, I would flag up the +following issues that may be helpful to the research team: + +- The data collected is referred to as "public", and as I understand + it consists of discussion forum posts etc associated with specific + "darkweb" topics. While, the "public" nature of those posts does to + some extent mitigate the risks introduced by the research per se, + that data has the potential to be personally identifiable, + particularly when it is subject to coding on the basis of the + content. Thus I would advise the researchers to seek advice at their + institution on whether specific protocols and approvals are needed + when handling such PII. I know for a fact that institutions in the + EU -- where horizontal data protection provisions are in place -- + would have to go through a (lightweight) approval process to collect + and handle such personal information. Probably procedures to ensure + the "anonymity" of the coded transcripts would also have to be + described as part of the approval process. + +- There is a little ambiguity in the description in relation to the + phrase "compare the views and products of the marketplaces". This + may mean simply browsing the pages of underground marketplaces, + which I think is fine (subject to the above). However, if products + are to be bought a certain amount of care should be taken. (1) the + safety of researchers should be thought of when it comes to payment + options, as well as shipping addresses -- ensuring that the + researchers personal information does not end up in the hands of + criminal organizations; (2) there are delicacies associated with + purchasing controlled substances, or other restricted items or + material from specific jurisdictions -- and probably some sound + legal advice will be needed in case this is the plan; (3) there are + ethical issues about providing payment for, or to anyone involved, + in criminal activity, since this may be seen as financially + supporting crime. Note that doing the above for research purposes + per se, is probably not a sufficient moral or legal defence, and + some sound legal & ethical reasoning may be required -- as well as + clear protocols to minimize risks to researchers or society at + large. + +- Besides the above, the research seems to be using Tor as a browser; + it does not involve any access that all other Tor users would not + have (eg. it does not involve observing traffic, running + infrastructure or even hidden services); and no other streams of + data, besides what is made available by hidden services, is likely + to be affected. Thus, I would think that the usual protocols for + collecting PII, and safely interacting with potentially criminal + activity while conducting research, should cover most concerns. + +- Beyond the strict remit of the board: this does sound like an + interesting project! + +--------------------------------------------------------------- +Comments from Reviewer B +--------------------------------------------------------------- +[Note these are written in the context of Reviewer A's comments. -PFS] + +Interesting, I agree! + +I want to underscore two of Reviewer A's points: + +1) If you're giving money to bad people, you need to think through the +ethics of that. + +2) It's important to consider your own safety when you're buying arbitrary +things from arbitrary people on the Internet. + +Both of those are standard IRB topics, and not particularly Tor related, +so we are right to send them to their IRB for more thoughts on those. + +And then here's a third one: + +3) Some marketplaces (both in onionspace and on the insecure web) +require logins before you can browse the wares -- and some of them put +up barriers to creating the account. At what point do the pages behind +such login requirements stop counting as 'public'? "Anybody could have +done these eighteen steps, so the stuff I found after that isn't private" +is a slippery argument. + +But overall, sounds great, thumbs up! + + +--------------------------------------------------------------- +Comments from Reviewer C +--------------------------------------------------------------- +This looks like very interesting and potentially quite useful work. I +look forward to seeing its results. I see no show-stoppers, but I do +have a few safety recommendations and considerations. + +The proposed research is "limited to the coding of the articles that + we read that have been published for public view on the Internet + and Dark Internet as well as the products that we receive from + the purchasing we are going through." + +The researchers therefore conclude that there is no risk expected in +conducting this work. Construed strictly in terms of expected Tor +protocol use or gathering of Tor usage network data, that is +true. However there are a few concerns. + +1. Safety of the researchers is as important as safety of those +researched. While obviously you can give yourselves informed consent, +you should take the same precautions as when purchasing or downloading +anything from the Internet, perhaps with a slight increase in caution +if purchasing items or visiting forums that seem potentially to have +higher than normal likelihood of malicious activity, e.g., if focused +on sensitive or controversial issues or goods. That will of course +depend on the forums in which you participate. To the extent +practicable, you should at least protect your own identities and +network location. It would make sense to conduct all your research +via Tor running on a suitably up-to-date and protected system except +where something specific precludes that, e.g. visiting a forum/site +that restricts access from the Tor network). Discussing the context of +and extent to which such blockage is encountered could be a useful +research output of this work. + +2. "[P]ublished for public view" is not as straightforward as that +expression might seem. + +First of all, as Vitaly Shmatikov is fond of saying, there is no +PII... it's all PII. Cf. his work w/ Arvind Narayanan on deanonymizing +highly dimensional public data using, e.g., publicly posted IMDb +reviews. Coding information from multiple sources potentially runs +that risk, and the research should be conducted cognizant of the sorts +of concerns that research in this space has identified. + +Second, you have not said whether sites you will visit/purchase-from +require registration to participate. That is one indicator of privacy +assumptions. But whether the sites require registration or not, +certainly some forums assume information is to be shared only among +participants or otherwise expect discretion and respect for privacy, +e.g., forums for discussion amongst crime or disease abuse +victims. Similarly, for participants in a purchase or other financial +transaction. + +Third, even if information is publicly available, it may be that +original sources of that information intended it to remain private in +a way that is violated by public posting. Public posting may have +occurred when others violated those assumptions. + +None of these are Tor-specific safety considerations, but the +researchers should be cautious and cognizant of these themselves and +should make sure that their intended research is acceptable given the +guidelines or evaluation of UMD's IRB or its other institutional bodies +for research involving (even public) data about individuals. +

1 0

[research-web/master] add another set of documents to 2016-01 trsb case
by arma＠torproject.org 09 Aug '17

09 Aug '17

commit b98732baef0d3b8383a7f09c7b8d016555bc4d46 Author: Roger Dingledine <arma(a)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(a)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(a)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(a)bamsoftware.com> -To: Roger Dingledine <arma(a)mit.edu> -Cc: Lynn Tsai <lynntsai(a)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(a)esat.kuleuven.be> -To: tor-research-safety(a)lists.torproject.org, david(a)bamsoftware.com, - lynntsai(a)gmail.com, QI ZHONG <zhongqi92(a)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

1 0

[trunnel/master] Another spelling fix
by nickm＠torproject.org 09 Aug '17

09 Aug '17

commit c6e8a499f5a5f00113ea268cfcef9e7676c6ed96 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Aug 8 21:02:30 2017 -0400 Another spelling fix --- lib/trunnel/CodeGen.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/trunnel/CodeGen.py b/lib/trunnel/CodeGen.py index eae0265..e7ad11c 100644 --- a/lib/trunnel/CodeGen.py +++ b/lib/trunnel/CodeGen.py @@ -2854,7 +2854,7 @@ MODULE_BOILERPLATE = """\ } while (0) #if defined(__COVERITY__) || defined(__clang_analyzer__) -/* If we're runnning a static analysis tool, we don't want it to complain +/* If we're running a static analysis tool, we don't want it to complain * that some of our remaining-bytes checks are dead-code. */ int %(csafe_fname)s_deadcode_dummy__ = 0; #define OR_DEADCODE_DUMMY || %(csafe_fname)s_deadcode_dummy__

1 0

[trunnel/master] Fix a doubled word in the output.
by nickm＠torproject.org 09 Aug '17

09 Aug '17

commit 2aa86b0321a5fae99de1a1db2901f705165928f2 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Aug 8 21:00:22 2017 -0400 Fix a doubled word in the output. --- lib/trunnel/CodeGen.py | 2 +- lib/trunnel/__init__.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/trunnel/CodeGen.py b/lib/trunnel/CodeGen.py index 35073f9..eae0265 100644 --- a/lib/trunnel/CodeGen.py +++ b/lib/trunnel/CodeGen.py @@ -2821,7 +2821,7 @@ class ParseFnGenerator(CodeGenerator): self.w('ptr += remaining; remaining = 0;\n') HEADER_BOILERPLATE = """\ -/* %(h_fname)s -- generated by by Trunnel v%(version)s. +/* %(h_fname)s -- generated by Trunnel v%(version)s. * https://gitweb.torproject.org/trunnel.git * You probably shouldn't edit this file. */ diff --git a/lib/trunnel/__init__.py b/lib/trunnel/__init__.py index a783d60..cd65cf5 100644 --- a/lib/trunnel/__init__.py +++ b/lib/trunnel/__init__.py @@ -3,4 +3,4 @@ # a package. # -__version__ = "1.5.1" +__version__ = "1.5.2"

1 0

[tor/master] prop224: Add XXX about opaqueness of link_specifier_t.
by nickm＠torproject.org 09 Aug '17

09 Aug '17

commit 686891d67ebf69808ac3d2b2c98263d21a3fe143 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Aug 8 21:25:04 2017 +0300 prop224: Add XXX about opaqueness of link_specifier_t. --- src/trunnel/ed25519_cert.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/trunnel/ed25519_cert.h b/src/trunnel/ed25519_cert.h index 782bd5958..0aa953d17 100644 --- a/src/trunnel/ed25519_cert.h +++ b/src/trunnel/ed25519_cert.h @@ -59,6 +59,10 @@ struct link_specifier_st { }; #endif typedef struct link_specifier_st link_specifier_t; +/** XXX hs_link_specifier_dup() violates the opaqueness of link_specifier_t by + * taking its sizeof(). If we ever want to turn on TRUNNEL_OPAQUE we would + * need to refactor that function to do the coyp by encoding and decoding the + * object. */ #if !defined(TRUNNEL_OPAQUE) && !defined(TRUNNEL_OPAQUE_ED25519_CERT) struct ed25519_cert_st { uint8_t version;

1 0