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

[teor]

> On 21 Jun 2017, at 04:07, Brandon Wiley <brandon at blanu.net> wrote:
> 
>  If you have feedback on this draft, please send me your comments by July 20.

Thanks for putting this together.
It looks like it's taken a lot of work to do this and the implementation.

I seem to be missing some context:
What is the goal of writing this specification?

I'm going to assume you want to implement parts in tor and parts in Go.

Here is my feedback:

In general, have you searched tor trac for PT protocol bugs, and made
sure this spec doesn't suffer from the same issues?

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?

3.1. Pluggable Transport Naming

How are unique names coordinated?

When is a PT a different version of an older transport with the same
name? When does a PT need a new name?

3.2.1. Goals for interface design

Definitions:

The destination address (and many other terms) aren't defined
anywhere. Are they IPv4, IPv6, DNS, or protocol-specific?

If they are not just IPv4 addresses, please give examples with
other address types.

Maybe section 3.3.5.1 defines some of these terms?

3.3.1 Pluggable Transport Configuration Parameters

Optional Addresses:

Since the address is optional, what value is used when it is not
required by the transport?

It looks mandatory in the Go interface, but isn't mandatory in the
environmental variables. Can you please map each environmental
variable to the Go interface?

I ask because we have had some issues in Tor with PT 1.0,
because Tor Browser uses a fake IPv4 address for transports like meek.
This interacts really badly with ReachableAddresses and similar.

Any new Tor code will need to resolve this issue by using non-address
identifiers or a defined placeholder address.

We have also had bugs where tor connects to the actual bridge address
rather than a proxy. So using a placeholder address for all PTs might
be a good idea for security in tor.

Multiple Addresses:

If there are multiple addresses, are these separate instances of the
transport, or can one transport have multiple connections?
Does this differ between the client and the server?

For example, the same bridge can have an IPv4 and IPv6 address.
Or two different bridges can use the same PT.

How is this handled in tor and in Go?
(It's specified that each PT has zero or one addresses, but there
isn't anything explicit about using multiple addresses.)

Banned Addresses:

Tor users often configure ReachableAddresses (or similar) and expect
pluggable transports to respect them. Is there a standard way of
telling a transport which addresses it can't connect to?

Or, alternately, is there a standard way for a transport to tell tor
which addresses it is actually using *before* it connects to it?

Client Addresses:

The client protocol is missing a standard way to configure:
* a local bind address
* a remote server address
* other common PT info

Is this intentional?
If so, do we really want each transport defining its own slightly
different JSON keys for common items like addresses?
Even worse, what if they format addresses inconsistently?

This will be difficult to implement in applications if it is not
standardised.

I suggest we make the server address an environmental variable.

3.3.1.4 Command Line Flags

How is an environmental variable name turned into a command-line flag?
Or are the command-line flags different for each transport?
(Let's not do that, it would be annoying.)

You give examples, but some have typos:
obfs4proxy -state =/var/lib/tor/pt_state/
obfs4proxy - transports obfs3,scramblesuit
Obfs4proxy -options scramblesuit:key=banana;automata:rule=110;automata:depth=3

3.3.2. Pluggable Transport To Parent Process Communication

What is the correct IPv6 address quoting for CMETHOD and SMETHOD?
Please give an example in the text.

"Equal signs and commas MUST be escaped with a backslash."

This is unclear: equals signs and commas in Key and Value?
What about colons or backslashes?
(Otherwise, it is impossible to end a value with a backslash.)
Must Key be an identifier? What's the format?

Why not just use an existing escaping scheme?

"Tor: The ARGS are included in the transport line of the Bridge's extra-info document."

Really? This seems insecure. Do we publish bridge extra-infos anywhere?

3.3.5 UDP Support

The TOC breaks here.

3.3.5.1 Obfuscating Proxy Architecture

This section belongs at the top of the document.

3.3.5.2. Configuring the Transports

There are no details for how this works over UDP: what is the UDP
equivalent to Pluggable PT Client Per-Connection Arguments, and do
TCP implementations have to support that environmental variable as
well?

I suggest we standardise it as an environmental variable and
command-line flag, and make all transports support it.

3.3.5.5. Implementation of the PT Server

Is the text in this section two different sizes?

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170621/af06146c/attachment-0001.sig>