Year 1 and 2

1.1 Task 1: Obfuscated Channels Objective. To handle an adversary that observes and may control the entire network underlying RACE communications, we develop obfuscated channels in which communication is hidden within traffic generated by common applications. Working with external collaborators at the U.S. Naval Research Laboratory, this task develops a suite of obfuscated channels to support RACE goals for varying adversarial networks (i.e., deployment scenarios).

1.2 Task 2: Channel Integration and Analysis Objective. To develop tools for evaluating the performance and security of obfuscated channels at scale, both by themselves and when integrated with TA1 protocols. To apply those tools to RACECAR channels.

Extension : 24 months starts 2021-03-01

Activity one, pipeline to understand the blocking we see in practice:

Phase one:

1.1. Get some manual vantage points in key regions, and automate scans of vanilla Tor, default Tor Browser bridges, vanilla and obfs4 bridges (both from bridgedb and unpublished), and meek.

1.3. Work with our team plus the in-region contacts to investigate and learn from each potential blocking event, "post mortem analysis" style, to try to understand whether it's a false positive and pin down the point of failure.

1.4. Use this ongoing library of events to identify a set of wishlist features for the Tor client and the various transports for how they could make scans more accurate and/or more productive, for example by having Tor self-assess why it failed to bootstrap.

Phase two:

2.1. Publish ongoing scan results as a public (privacy-preserving as needed) dataset, and have a web page that highlights recent data and steers researchers toward trends/questions raised by the data.

2.2. Understand the OONI data format, and the constraints on OONI tests, to build a plan for either converting our data into the OONI data format, or adding some of our tests to the ooniprobe app, or some other smart way to integrate.

Phase three:

3.1. Continue to accumulate the library of event assessments, and maintain the map of the circumvention methods that are known to work in each region.

3.2. Integrate some of our data and some of our tests with OONI, based on the analysis in phase two. The initial analysis aims for depth, and here we try to expand the 'breadth' part.

3.3. Refactor and streamline with maintainability in mind: so we end up with a pipeline where we can easily add new circumvention methods to our censorship map and test set.

Activity two, endpoint censorship attacks on internet infrastructure

4.1. Identify the input components that feed into a bridge distribution framework, starting from:

• tracking reachability of bridges in various regions.
• understanding all the ways that censors can enumerate bridges, and thinking about how to recognize or detect if each is happening.
• tracking load on bridges to know which distribution strategies are working.
• approaches to maintain enough fresh proxies that we can rotate to new ones when they are needed.
• identity mechanisms for tying client activities together if needed, including what client-side state is needed for each.
• others?

4.2. Put these components together as a design based on the "Salmon" reputation bridge distribution framework, highlighting the missing and underspecified pieces.

4.3. Explore the parameter space, e.g. what rates of discovery vs rates of fresh bridges should be workable and what rates should be unworkable.

4.4. For each missing piece, enumerate and evaluate concrete options and recommend paths forward.