[tor-dev] Pluggable Transports 2.0, draft 1 Specification

[Yawning Angel]

NB: I'm personally not doing any circumvention related work at all and
I won't be the one implementing this regardless of what happens, so
feel free to disregard this.

On Sun, 26 Mar 2017 04:48:44 -0500
Brandon Wiley <brandon at blanu.net> wrote:
> As was discussed in the Pluggable Transports session at TorDev
> Amsterdam, the Pluggable Transports 2.0, draft 1 specification
> [https://www. pluggabletransports.info/spec/pt2draft1] was created by
> a committee of censorship circumvention tool developers: Tor,
> Lantern, Psiphon, and uProxy. It specifies a version of Pluggable
> Transports that meets the needs of multiple circumvention tools.

The formatting is all fucked up, so I'm commenting based off the PDF
version.

> There is one major change that has implications for tor, which is
> that the Pluggable Transports 2.0, draft 1 IPC protocol uses a
> different type of SOCKS authentication mechanism, which allows for
> larger parameters to be send to transports.

Why JSON, and how is that better than the binary Tor Prop 229 SOCKS5
extension?

Unless I'm missing something, the draft as is, does not fully specify
how exactly the new authentication method is supposed to work and is
currently unimplementable.  (How is the length of the serialized body
supposed to be determined by the SOCKS proxy side?)

> We are currently working on a 2nd draft of this specification, which
> will incorporate changes and errata from the community censorship
> circumvention tool community. For instance, syntactic errors in the
> documentation of the Go interface will be fixed in draft 2. Tor
> developers participated in the specification meetings, and now
> feedback from the overall Tor community is requested for
> incorporation in the next draft. There will also likely be a 2.1
> specification process, possibility starting August, where we will
> consider larger changes.

As it stands I don't see a good reason for this to be implemented by
Tor.  The larger args is nice, but that can be done with the existing
spec plus Prop 229[0].  The new spec does nothing to address things that
would actually be a good reason to revise the spec either, like making
dual stack bridges actually work, or adding notation for AF_LOCAL
addresses so that containerization isn't painful client side.

Am I missing something here?  This looks like the old spec with
a not-invented-here JSON based Prop. 229 extension and a bunch of
programming language bindings that I'll never use, that defeat the
purpose of the whole "pluggable" notion in the first place.

(Yes, I'm aware that "What Yawning considers important in a new spec"
 has been and apparently still is different from what other people
 considers important in a new spec.  But if you're going to revise the
 spec, at least fix the dual stack problem for fuck's sake.)

Regards,

-- 
Yawning Angel

[0]: Or "Just use Socks4a, because IPv6 is fucking broken server side
anyway".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170327/205ca196/attachment.sig>