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.
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.
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.
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@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,
Thank you for the feedback on the specification draft, Yawning. We will take all of this feedback into account in the next draft.
Some specific points are addressed below.
On Mon, Mar 27, 2017 at 12:27 AM, Yawning Angel yawning@schwanenlied.me wrote:
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@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.
I will talk to the website maintainer about the formatting. Here is a link to the PDF version for anyone else that would like to read it: https://www.pluggabletransports.info/assets/PTSpecV2Draft1.pdf
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?
I was not familiar with Tor Prop 229. It does seem to have a similar purpose. I will read this proposal and get back to you.
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?)
Thank you for this feedback, this is very helpful. It seems that this section of the specification draft (3.3.4. Pluggable PT Client Per-Connection Arguments) needs some additional work. We will address this in the next draft.
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.)
I am familiar with the dual stack problem generally, where servers have both IPv4 and IPv6 IP addresses. I was not involved in any conversations regarding the dual stack problem for Pluggable Transports specifically. If you could point me to any documentation on this issue, that would be helpful. Alternatively, if you could explain what the issue is and what possible solutions you'd like to see in a future Pluggable Transports specification, that is something we could make happen in future specifications revisions.
Regards,
-- Yawning Angel
[0]: Or "Just use Socks4a, because IPv6 is fucking broken server side anyway".
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, 27 Mar 2017 04:03:47 -0500 Brandon Wiley brandon@blanu.net wrote:
I am familiar with the dual stack problem generally, where servers have both IPv4 and IPv6 IP addresses. I was not involved in any conversations regarding the dual stack problem for Pluggable Transports specifically. If you could point me to any documentation on this issue, that would be helpful. Alternatively, if you could explain what the issue is and what possible solutions you'd like to see in a future Pluggable Transports specification, that is something we could make happen in future specifications revisions.
None of the things I've mentioned are new concerns, and I brought all of them up (and more) a long time ago back when I was giving thought to the PT spec.
I've basically given up at this point, and to be honest I gave up shortly after I initially started making noises about improving the spec because it was clear that while I was trying to improve the existing interface while preserving the overall architecture, everyone else was far more interested in "lets make everything into a bunch of library code".
https://lists.torproject.org/pipermail/tor-dev/2015-September/009432.html
https://trac.torproject.org/projects/tor/ticket/21261 https://trac.torproject.org/projects/tor/ticket/11211
Regards,
Hi Yawning. Thank you for providing these links. This is very helpful. I will make sure that these issues are discussed at the next specification meeting.
On Mar 28, 2017 8:36 AM, "Yawning Angel" yawning@schwanenlied.me wrote:
On Mon, 27 Mar 2017 04:03:47 -0500 Brandon Wiley brandon@blanu.net wrote:
I am familiar with the dual stack problem generally, where servers have both IPv4 and IPv6 IP addresses. I was not involved in any conversations regarding the dual stack problem for Pluggable Transports specifically. If you could point me to any documentation on this issue, that would be helpful. Alternatively, if you could explain what the issue is and what possible solutions you'd like to see in a future Pluggable Transports specification, that is something we could make happen in future specifications revisions.
None of the things I've mentioned are new concerns, and I brought all of them up (and more) a long time ago back when I was giving thought to the PT spec.
I've basically given up at this point, and to be honest I gave up shortly after I initially started making noises about improving the spec because it was clear that while I was trying to improve the existing interface while preserving the overall architecture, everyone else was far more interested in "lets make everything into a bunch of library code".
https://lists.torproject.org/pipermail/tor-dev/2015-September/009432.html
https://trac.torproject.org/projects/tor/ticket/21261 https://trac.torproject.org/projects/tor/ticket/11211
Regards,
-- Yawning Angel
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Brandon Wiley -
Yawning Angel