Re: [tor-dev] Pluggable Transports 2.0 Specification, Draft 2

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Wed, Jun 21, 2017 at 01:16:20PM +1000, teor wrote:
> In general, is there a separate document or proposal that describes
> how Tor will implement the relevant interfaces? There doesn't seem
> to be much on Tor-specific issues in this spec.
> 
> There is one "Tor" note in the spec, maybe it should be in that
> separate document? Or maybe there should be more Tor notes in the
> spec?

As I understand it, one of the goals of the PT 2.0 spec is to make it
easier for projects *other* than Tor to use pluggable transports. The
current spec (the 1.0 spec) basically doesn't work for anyone other than
desktop Tor--this is something we've heard over and over from other
projects that use circumvention, and Brandon is well plugged in to those
conversations. Even closely affiliated projects like Orbot haven't been
able to use pluggable transports strictly according to the spec, because
of the various constraints on mobile platforms.

What various circumvention developers have said they prefer, is a
Go-based API. They would rather link against a library, than do the
whole subprocess-and-stdout thing that the PT 1.0 spec requires. That's
the reason for introducing the new Go stuff in the 2.0 spec. Inside and
outside Tor, a lot of projects have converged on implementing their
circumvention code in Go. The API of the 2.0 spec is based on the
internal architecture of obfs4proxy, which is de facto the main
implementation of most of Tor's pluggable transports.

If I understand correctly, Tor wouldn't have to implement glue code to
interface with the Go API. It could continue spawning subprocesses,
similar to what it does now. The executables it invokes, if they are
written in Go, will likely internally use a PT library that uses the 2.0
spec's API, but Tor wouldn't have to know those details.

PT 1.0 succeeded in being "pluggable" in one sense: it's easy to hotswap
a lot of circumvention technologies within Tor. But it failed in being
"pluggable" in another sense: it's not easy to share common transport
modules beyond Tor (in either direction). It would be great if the new
spec can realize that second sense of pluggability.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev