Formalize and document what it takes for a PT to get deployed.

It would be good to formalize what it takes to get a PT to be considered for deployment beyond the rough guidelines we have as part of our Sponsor S/T draft. I have some ideas here about things that should be considered that aren't, that other people are likely to disagree about, so discussion is needed.

The last 3 PTs that got deployed were FTE, ScrambleSuit and obfs4.

• What did we do?
• Out of what we did, what was right?
• Out of what we did, what was wrong?
• What did we consider that we should ignore in the future?
• What did we not consider that we should in the future?
• Who's going to do all the evaluation work?

added SponsorS component::circumvention/pluggable transport owner::yawning priority::medium severity::normal status::new type::task labels

Trac:
Cc: asn, dcf, mikeperry to asn, dcf, mikeperry, isabela

Here's a list of things that come to my mind with probably not enough thought:

1. Pluggable Transport MUST NOT have any byte signatures that uniquely identify their usage on the wire (including usage of transport-specific DNS names, certificates, or other aspects of operation that may trigger the operating system to reveal their usage to the network).
2. Pluggable Transports MUST be capable of authenticating the Tor relay identity key of their underlying Tor bridge (via specifying an identity fingerprint in PT bridge lines).
3. Pluggable Transports MUST require that a client completes a handshake that proves possession of an authentication token/secret (in order to prevent scanning and probing). High collateral damage and/or shared infrastructure transports such as meek MAY be exempt from this requirement.
4. Pluggable Transports MUST be easy for bridge operators to update automatically and securely (such as via Debian package, custom apt/yum repository with GPG signing, or some similar authenticated update mechanism). These updates SHOULD be possible to easily perform over Tor.
5. Pluggable Transports MUST NOT reveal their installation or update activity to third parties in a way that allows them to identify either the full set of installed bridges, or the set of clients.
6. Pluggable Transports SHOULD have a wire protocol that optionally supports defenses against packet length analysis and similar statistical attacks.
7. Pluggable Transports SHOULD be written in a memory safe language (python, golang, rust, etc).
8. Pluggable Transports SHOULD have minimal additional disk space requirements for including their runtime in Tor Browser and similar client software packages.
9. A single copy of this runtime SHOULD be shared by all bundled Pluggable Transports written in the same language.

We can then assign point scores to the various SHOULD statements, and then decide some scoring threshold for inclusion. With more thought, we can probably generate a ton more SHOULD statements.

Some thoughts/additional exceptions: Replying to mikeperry:

2. Pluggable Transports MUST be capable of authenticating the Tor relay identity key of their underlying Tor bridge (via specifying an identity fingerprint in PT bridge lines).

Flashproxy like systems may have issues with this (At least I seem to recall the bridge line being entirely synthetic).

4. Pluggable Transports MUST be easy for bridge operators to update automatically and securely (such as via Debian package, custom apt/yum repository with GPG signing, or some similar authenticated update mechanism). These updates SHOULD be possible to easily perform over Tor.

Shared infrastructure transports such as meek MAY be exempt from this requirement.

5. Pluggable Transports MUST NOT reveal their installation or update activity to third parties in a way that allows them to identify either the full set of installed bridges, or the set of clients.

Shared infrastructure transports such as meek MAY be exempt from this requirement.

Some additions: 10. Pluggable Transports MUST be capable of being built deterministically by the Tor Browser build system. 11. Pluggable Transports MUST support all officially supported Tor Browser platforms, and SHOULD additionally support Android. 12. Pluggable Transports MUST NOT operate in a manner that is harmful to the health of the Internet as a whole (Eg: TCP friendly congestion control MUST be implemented if required). 13. Pluggable Transports MUST NOT operate in a manner considered unethical (Subjective. Want to prevent stealing resources, using a botnet, etc).

We should figure out who is responsible for obtaining a sufficient pool of bridges for a given transport. It just happened for ScrambleSuit, I begged people and wrote e-mails for obfs4, not sure if there are a lot of FTE bridges....

14. Protocols based on mimicry MUST NOT fall to trivial Dead Parrot style distinguishers.

I am deeply wary of the fast-and-loose flashproxy model for lots of reasons. If the introducer can't manage to authenticate itself, and it can't tell you how to authenticate your traffic to the flashproxy bridges it gives you, then long-term I am against it and anything that behaves like it. In fact, I would be in favor of killing it until we can fix these issues, especially if we're thinking of trimming down the supported PT list anyway. I really, really don't want a future WebRTC-based version of flashproxy to end up as such an unauthenticated free-for-all mess, for example.

I agree with the rest of your comments. For point 13, we could make the phrasing focused on requiring the consent of the person/entity who is ultimately accepting PT connections (not counting passive routers and intermediary middleboxes). That may cover the issues you're concerned about? It would also cover the related case of "ZOMG! I can deploy ONE MEEELION bridges if I pay this sketchy ad network $50 to turn a ton of random browsers into WebRTC bridges!!"

Replying to mikeperry:

I am deeply wary of the fast-and-loose flashproxy model for lots of reasons. If the introducer can't manage to authenticate itself, and it can't tell you how to authenticate your traffic to the flashproxy bridges it gives you, then long-term I am against it and anything that behaves like it. In fact, I would be in favor of killing it until we can fix these issues, especially if we're thinking of trimming down the supported PT list anyway. I really, really don't want a future WebRTC-based version of flashproxy to end up as such an unauthenticated free-for-all mess, for example.

ACK. We should probably make this requirement know before people go too far into the development of that. I don't think it's a total dealbreaker even for flashproxy but would require code changes, for something that's basically not used at all (Not worth it IMO).

I agree with the rest of your comments. For point 13, we could make the phrasing focused on requiring the consent of the person/entity who is ultimately accepting PT connections (not counting passive routers and intermediary middleboxes). That may cover the issues you're concerned about? It would also cover the related case of "ZOMG! I can deploy ONE MEEELION bridges if I pay this sketchy ad network $50 to turn a ton of random browsers into WebRTC bridges!!"

Works for me.

Hi there, I started compiling this here:

https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/GuidelinesForDeployingPTs

I know there is ongoing discussion here, I added a note to the top explaining that. Hope is ok.

Replying to mikeperry:

I am deeply wary of the fast-and-loose flashproxy model for lots of reasons. If the introducer can't manage to authenticate itself, and it can't tell you how to authenticate your traffic to the flashproxy bridges it gives you, then long-term I am against it and anything that behaves like it. In fact, I would be in favor of killing it until we can fix these issues, especially if we're thinking of trimming down the supported PT list anyway. I really, really don't want a future WebRTC-based version of flashproxy to end up as such an unauthenticated free-for-all mess, for example.

I'm fine with removing flashproxy from the bundle.

Mike, the JavaScript flash proxies are just dumb pipes to the Tor bridge. They don't have an identity that is separately authenticated. You still authenticate the Tor bridge, as long as you have a fingerprint on the bridge line (which we do now).

Trac:
Cc: asn, dcf, mikeperry, isabela to asn, dcf, mikeperry, isabela, gk

Pluggable Transports SHOULD be usable with local (corporate) proxies on all supported platforms.

I mainly want to avoid nightmares likes #12381 (closed) falling back onto our feet (again) in a number of ways. Simultaneously, the benefit of a new pluggable transport might outweigh issues in this regard, though, especially if not all platforms are affected/or only platforms with a small user base.

Trac:
Sponsor: N/A to N/A

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

mentioned in issue #17428 (closed)

moved to tpo/anti-censorship/pluggable-transports/trac#16756 (moved)