Dust2 Transport Evaluation (Preliminary)

Dust2 is an engine/framework for implementing protocols that evade Shallow Packet Inspection/Deep Packet Inspection based filtering. It consists of two layers, a "crypting" layer which provides link layer encryption and authentication, and a "shaping" layer which transforms the uniformly random stream generated by the "crypting" layer to have statistical properties desired by the author.

The transformation is dependent on models, of which as of the time of this writing, three exist that attempt to mimic the statistical properties of HTTP, HTTPS and RTSP. The transformation also is capable of altering packet length and timing.

1. Review Coverage and Reviewability Evaluation

1.1 Is the software published, and is it entirely free / open source software?

The software is implemented in two parts, the actual engine code exists as a separate Go library distributed under an MIT style FOSS license with 2 dependencies that are under BSD style FOSS licenses, and as an addon transport to the FOSS obfs4proxy suite that uses the engine code as a library.

1.2 How well documented is the design?

The original Dust protocol is well documented, however the documentation for Dust2 appears to be a work in progress. The "crypting" (link layer encryption) layer is documented, however the all important "shaping" layer appears not to be documented yet.

Crypting: https://github.com/blanu/Dust/blob/master/docs/v2/crypting.md Shaping: https://github.com/blanu/Dust/blob/master/docs/v2/shaping.md

1.3 How much existing review has been done? Is the project active?

(NB: I'm currently reviewing the code, it appears to be well commented and written, but this is not complete yet. Development appears to have been paused at the end of the T grant. I'm not sure if they are waiting for me to finish review and merge the obfs4proxy integration or not, and I have reservations about merging the code at this point, see 2.1/3.3/3.4)

1.4 What is the design's deployment history?

Dust2 has not been deployed outside of testing environments yet, though it would be easy to include it in a Tor Browser alpha release series or Orbot release series due to it's leverage of the obfs4proxy framework.

2 Design Evaluation

2.1 How difficult or expensive will it be to block the design?

(NB: Preliminary)

With no "shaping", Dust2 is essentially equivalent to obfs4 with slightly different link layer encryption primitives (Skein is used instead of Salsa20 to provide confidentiality).

The difficulty in evaluating this comes mostly from the shaping layer and the relative unknown of adversary capabilities. If the shaping is sufficient to have DPI systems mis-categorize the stream (Eg: 'Dust2_HTTP' gets classified as HTTP), it is extremely vulnerable to Dead Parrot style attacks due to the stated design goals only attempting to mimic rough statistical properties rather than the full protocol. The false positive rate can be brought down to near zero with followup active probing and observing that a 'Dust2_HTTP' server does not behave like the real thing.

2.2 What impact on anonymity does the design have, if any?

There is no negative anonymity impact with the Dust2 protocols, and it is possible that the shaping layer may add limited resistance to certain fingerprinting attacks against the user's anonymity.

However any such additional resistance is coincidental as such properties were not part of the primary design goals when the protocol was created.

2.3 What is the design's overhead in terms of computational costs and bandwidth?

(TODO: I still need to write benchmarks for this. The shaping layer may be expensive in both cases, but I don't know enough yet.)

2.4 How resilient is the design to active probing?

The "crypting" layer provides similar active probing resistance to obfs4, in that a shared secret (the Bridge's public key and an opaque identifier) is required to establish a connection, and thus is immune to active probing attacks at that layer.

However, as mimicry is attempted, it is extremely vulnerable to Dead Parrot style active probing that seeks to distinguish something that is attempting to look like another protocol versus the real thing (See 2.1).

3 Implementation Evaluation

3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already?

Yes, the Dust2 transports integrate into the obfs4proxy suite that uses the PT API.

3.2 Is the implementation cross-platform? How about mobile support?

The Go implementation is portable and can be deployed on any platform that the Go compiler and runtime can target (Linux, Windows, Darwin, and Android), as it integrates into obfs4proxy which is already deployed on all platforms officially supported by the Tor Project.

3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like?

As it integrates into obfs4proxy, it is capable of being built deterministically, and will be trivial to integrate into the Tor Browser's build process.

Packaging remains an open question as building Debian packages for Go applications requires making separate packages for all dependencies. While this is not an insurmountable hurdle, it is partially up to the Debian package maintainer, and may end up as a hurdle to bridge deployment.

However once bridge side packaging has been resolved, it will be just another set of transports provided by the already widely deployed obfs4proxy binary.

3.4 How is the implementation's code from a security and maintainability perspective?

Dust2 is written in Go which is a memory safe language. Test coverage appears to be somewhat sparse, and could be improved, however the code has comprehensive Godoc comments and is easy to follow.

The primary maintainability concern here is that it is anticipated that the models could/should be improved periodically (especially if targeted Dead Parrot + follow up active probe type attacks appear in the wild), and due to the lack of documentation on the "shaping" layer (including how to generate models) it will be difficult for the Tor Project to fully utilize the capabilities of the engine and have it remain relevant.

3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics?

As it integrates into obfs4proxy, it fully supports the Extended ORPort mechanism and thus provides metrics information.