[tor-bugs] #29285 [Circumvention/Pluggable transport]: Improve the PT spec and how PTs interface with Tor

[Tor Bug Tracker & Wiki]

#29285: Improve the PT spec and how PTs interface with Tor
-------------------------------------------------+-------------------------
 Reporter:  cohosh                               |          Owner:  phw
     Type:  project                              |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:
Component:  Circumvention/Pluggable transport    |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2,      |  Actual Points:
  anti-censorship-roadmap                        |
Parent ID:                                       |         Points:  15
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor28-must
-------------------------------------------------+-------------------------
Changes (by phw):

 * status:  new => assigned
 * cc: arma, gaba (added)
 * priority:  Medium => High
 * keywords:  network-team-roadmap-2019-Q1Q2 => network-team-
     roadmap-2019-Q1Q2, anti-censorship-roadmap
 * points:   => 15
 * sponsor:  Sponsor19 => Sponsor28-must
 * owner:  (none) => phw


Comment:

 Here's an incomplete list of issues with our current spec:
 * The PT should be able to communicate its bootstrap status to the
 invoking process.
 * The spec should incorporate the proposed dormant mode (see #28849).
 * Some PTs such as meek and snowflake don't rely on an IP address. The
 current workaround is to use awkward pseudo IP addresses.
 * Other transports may want to rely on multiple IP address. We need to
 reconsider the outdated notion of a bridge line. The PT should be able to
 communicate its bootstrap status to the invoking process.
 * The spec should incorporate the proposed dormant mode (see #28849).
 * Some PTs such as meek and snowflake don't rely on an IP address. The
 current workaround is to use awkward pseudo IP addresses.
 * Other transports may want to rely on multiple IP address. We need to
 reconsider the outdated notion of a bridge line.

 And here's an incomplete list of existing library implementations:
 * [https://github.com/operatorfoundation/transport A seemingly unnamed
 Swift implementation] of the v2.1 specification, maintained by the
 Operator Foundation.
 * [https://github.com/guardianproject/AndroidPluggableTransports PLUTO2]
 is a Java implementation of the v2.x specification, maintained by the
 Guardian Project.
 * [https://gitweb.torproject.org/pluggable-transports/goptlib.git/
 goptlib] is a Go implementation of the v1.0 specification, maintained by
 the Tor Project.
 * [https://gitweb.torproject.org/pluggable-transports/pyptlib.git/
 pyptlib] is a Python implementation of the v1.0 specification, (formerly)
 maintained by the Tor Project.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29285#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online