comments on the blocking-resistant anonymity system draft

[yousifnet <yousifnet@xxxxxxxxx>]

I read the draft paper "design of a blocking-resistant anonymity
system" and I have some comments that I would like to share with you
all.

First, I think a blocking-resistant design is perhaps the most
exciting development in the tor network since hidden-services
especially for those of us living in countries with regimes going to
great lengths to censor and inhibit the internet's power to spread
information. This design would act as a workaround to many
access-blocking vulnerabilities that Tor suffers from such as having a
central point of failure (namely the directory authority servers) or
iterating stable tor servers and blocking access to them.

In regards to section 5.1 on "Bridge relays", from reading the
section, it wasn't clear that bridge relays are basically entry nodes
that publish to a different directory authority in a rather "stealth"
mode. I got the impression that bridge relays were basically
forwarding data to the tor network with no processing involved (i.e.
they are not part of the circuit and act only as a mediator) but this
confusion was cleared when I read your last email to the  or-dev
mailing list and you explicitly stated that bridge relays are
basically entry nodes that publish to a different directory authority.

Also it was mentioned that Tor developers will be encouraging users to
turn bridging on in their Tor software. Instead of encouraging users
to turn bridging on, why doesn't Tor default to enabling it and give
the user the option to turn it off. Doing this will have a tremendous
effect on the number of users running bridges and even ordinary
routing nodes. From how I understood the design of the tor network,
guard nodes are usually servers that are stable and reliable enough to
act as the first point of entry into the network. When users start Tor
and the use of bridges is not enabled, they could announce themselves
automatically as bridges and as soon as they reach enough stability,
they can be moved from the bridge directory authority to the main
directory authority but they would never go back. Since the user-base
is not constant all the time, this would not have any significant
effect on the number of bridges available because they are after all
constantly changing. This would ensure that not only bridge users are
going to benefit from them but the whole tor network. Let me elaborate
on why this behavior should be the default.

Users usually tend not to turn off a feature that would eventually
hurt the network they are using. The less nodes we have, the greater
the chance of congestion to occur. Take popular p2p networks as an
excellent example. The developers turn uploading on by default and the
benefit to the network is greatly emphasized to the user. The result
is that users with uploading enabled outnumber those with special
circumstances that do not permit them to enable uploading. Emphasizing
that the health of the network is a community effort and the
responsibility of the community results in the user feeling morally
inclined to contribute rather than leech off of the network.

Moreover, users usually tend to assume that any option turned off by
the developers requires expert knowledge. Especially applicable to
beginners, they feel uncertain and fearful of the consequences and so
they just leave it off. However, if the option was on the user would
assume that it is safe to leave it on and this is probably true in the
case of bridge relays and perhaps even entry nodes as long as they
don't act as exit nodes. Perhaps the only consequence is bandwidth and
the user can be notified about this in the readme file, help
documents, the manual etc.

In regards to section 5.2 "bridge directory authority", I second your
suggestion that bridge relays should at least try to use port 443 as
ORPort mainly due to the fact that this port is almost guaranteed to
be open in the most restrictive firewall situations.

In regards to section 7.4 "public bridges with central discovery", we
run into the same limitation that the current tor network is suffering
from. For instance, the first, second, and third strategies is limited
to the user's ability to connect to a central directory authority.
Though, if the user managed to connect to the tor networks through a
previously known bridge this limitation would cease to exist. However,
the forth, fifth, and sixth strategies seem not to suffer from this
limitation. I am particularly fond of the mailing list strategy that
requires email addresses from reputable free email providers. Perhaps
an enhancement to this strategy would be to send bridge addresses as
an encrypted file attachment that the user copies to the directory
that has torrc "~/.tor" or "/etc/tor".

In regards to section 7.6 "assessing whether bridges are useful", the
only comment I have on this section is that the requirement for
stability ought to be more lenient than guard nodes mostly because a
more lenient requirement would reduce the chance that an adversary
could find the bridge and block access to it. Secondly, if ordinary
users start running bridges we could certainly leverage the excess
bandwidth/processing power for the tor network. I understand that
stability is needed if we are to provide high quality connections.
Perhaps reaching a compromise between quality and security is the
optimal solution but since users of bridges are already at a greater
risk,  more emphasis ought to be directed towards security

can't wait to see the implementation!

Best,
 Yousif Al Saif