[tor-commits] [research-web/master] add files for 2017-02 trsb case

[arma@xxxxxxxxxxxxxx]

commit 7cb518589a55a570d2afe91e9fbc3285cf691e44
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
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@xxxxxxxxxxx>
+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@xxxxxxx>
+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
+

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits