Opened 8 years ago

Closed 8 years ago

#4625 closed project (fixed)

Figure out what to do with the FC paper proposing adaptive bridge address distribution

Reported by: karsten Owned by:
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: arma, phobos Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We had a deliverable for sponsor F year 1 "analyze FC paper proposing adaptive bridge address distribution," and we left it in a good enough state for the milestone, but with more work to do. The status on November 30 was:

"There are four building blocks involved here: 1) A way to discover how much use a bridge is seeing from a given country: see the WECSR10 paper and usage graphs. 2) A way to get fresh bridge addresses over time: see this blog post. 3) A way to discover when a bridge is blocked in a given country: see this blog post. 4) Distribution strategies that rely on different mechanisms to make enumeration difficult. The bottom of the bridge-testing blog post gives an overview of the Proximax idea. We've uncovered a further set of research questions that will need more attention in year2."

I'm creating this ticket to remind us that there's still work to do. but not for the November 30, 2011 milestone. From an IRC conversation on December 1, 2011:

12:47:40 < karsten> armadev: should I create a ticket "Figure out 
                    what to do with the FC paper proposing adaptive 
                    bridge address distribution," add the text from 
                    the year1 page, assign it to the sponsor f march 
                    2012 milestone, and call the year1 item done?
12:48:25 < armadev> karsten: sure. except i'm not sure if we'll have 
                    anything useful to say by march 2012, so we may 
                    end up putting it off at that point.
12:49:21 < armadev> karsten: a lot of it depends on how the "deploy 
                    some bridge reachability testers" and "solve all 
                    the bridge enumeration attacks" items go
12:49:55 < armadev> karsten: since the whole proximax idea is based 
                    on the premise that the only way for the
                    adversary to learn bridges is to get told them by
                    a corrupt or weak distribution channel
12:50:57 < armadev> karsten: i haven't decided yet if the fact that 
                    these other enumeration attacks are going to be 
                    an ongoing problem is enough to kill the proximax 
                    design, or just enough to slow it down.
12:51:36 < armadev> for example, against an adversary who likes dpi, 
                    it's a pretty dumb strategy
12:51:58 < karsten> armadev: hmmm. would it make more sense for you 
                    to create the ticket, rather than me creating it 
                    and you correcting it?
12:52:37 < armadev> just paste all of this into it and we can sort it 
                    out later

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by karsten

Cc: arma added

Roger, can we assign this ticket to you?

comment:2 Changed 8 years ago by karsten

Milestone: Sponsor F: March 15, 2012

Removing this from the sponsor F milestone after talking to Roger, because we're not really supposed to deliver this in March.

comment:3 Changed 8 years ago by arma

I have an answer now though:

Adversaries are increasing enumerating bridges (or making bridges moot) by other mechanisms than defeating our distribution strategies -- DPI, scanning, etc. So until we solve most of the items on https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges we can't deploy the idea from this paper. And it likely won't do us much good to consider details of how we would deploy it in the future since the future keeps changing so much.

So said more simply, there's a fifth building block we need: "we need to make defeating the distribution strategies the best way to identify or block bridges."

Karsten, feel free to put this back on the SponsorF list if you like (since I think it was a year1 thing originally?)

comment:4 Changed 8 years ago by arma

(and once you've done that, feel free to close)

comment:5 Changed 8 years ago by karsten

Resolution: fixed
Status: newclosed

Updated the year 1 wiki page to say what I think you mean. Please rephrase if necessary. Closing. Thanks!

comment:6 Changed 8 years ago by phobos

Resolution: fixed
Status: closedreopened

This is on the 'should do' list for due by March 2012.

comment:7 Changed 8 years ago by arma

Yeah? Did it fail to get onto our wiki page somehow?

https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year2

comment:8 in reply to:  7 Changed 8 years ago by karsten

Replying to arma:

Yeah? Did it fail to get onto our wiki page somehow?

https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year2

Is this question for me? That wiki page is based on your mail "SponsorF year two tasks" from November 14, 2011. I don't see this deliverable in that email.

comment:9 in reply to:  6 Changed 8 years ago by karsten

Replying to phobos:

This is on the 'should do' list for due by March 2012.

I still don't understand what you mean here. Can you explain?

comment:10 Changed 8 years ago by arma

Cc: phobos added

comment:11 Changed 8 years ago by karsten

Resolution: fixed
Status: reopenedclosed

After talking to phobos we now agree that this was a year 1 item and is unrelated to year 2 and the 'should do' list for due by March 2012. Closing.

Note: See TracTickets for help on using tickets.