clean up, and make progress on, the discovery section.

svn:r8925

doc/design-paper/blocking.tex

@@ -384,7 +384,7 @@ getting new addresses for them as the old addresses are blocked, they
 aim to have a large number of entirely independent proxies, each managing
 its own (much smaller) set of users.
 
-As the Circumventor site~\cite{circumventor} explains, ``You don't
+As the Circumventor site explains, ``You don't
 actually install the Circumventor \emph{on} the computer that is blocked
 from accessing Web sites. You, or a friend of yours, has to install the
 Circumventor on some \emph{other} machine which is not censored.''
@@ -747,7 +747,7 @@ situations where it's more convenient or more secure to learn the bridge's
 identity fingerprint as well as instead, while bootstrapping? We keep
 that question in mind as we next investigate bootstrapping and discovery.
 
-\section{Discovering and maintaining working bridge relays}
+\section{Discovering working bridge relays}
 \label{sec:discovery}
 
 Tor's modular design means that we can develop a better relay component
@@ -757,10 +757,38 @@ unfortunate fact is that we have no magic bullet for discovery. We're
 in the same arms race as all the other designs we described in
 Section~\ref{sec:related}.
 
-In this section we describe three approaches to adding discovery
-components for our design. Note that we should deploy all the schemes
-at once---bridges and blocked users can then use the discovery approach
-that is most appropriate for their situation.
+In this section we describe a variety of approaches to adding discovery
+components for our design.
+
+\subsection{Bootstrapping: finding your first bridge.}
+\label{subsec:first-bridge}
+
+In Section~\ref{subsec:relay-together}, we showed that a user who knows
+a working bridge address can use it to reach the bridge authority and
+to stay connected to the Tor network. But how do new users reach the
+bridge authority in the first place? After all, the bridge authority
+will be one of the first addresses that a censor blocks.
+
+First, we should recognize that most government firewalls are not
+perfect. That is, they may allow connections to Google cache or some
+open proxy servers, or they let file-sharing traffic, Skype, instant
+messaging, or World-of-Warcraft connections through. Different users will
+have different mechanisms for bypassing the firewall initially. Second,
+we should remember that most people don't operate in a vacuum; users will
+hopefully know other people who are in other situations or have other
+resources available. In the rest of this section we develop a toolkit
+of different options and mechanisms, so that we can enable users in a
+diverse set of contexts to bootstrap into the system.
+
+(For users who can't use any of these techniques, hopefully they know
+a friend who can---for example, perhaps the friend already knows some
+bridge relay addresses. If they can't get around it at all, then we
+can't help them---they should go meet more people or learn more about
+the technology running the firewall in their area.)
+
+By deploying all the schemes in the toolkit at once, we let bridges and
+blocked users employ the discovery approach that is most appropriate
+for their situation.
 
 \subsection{Independent bridges, no central discovery}
 
@@ -782,6 +810,9 @@ somebody else they trust. This scheme brings in appealing but complex game
 theoretic properties: the blocked user making the decision has an incentive
 only to delegate to trustworthy people, since an adversary who learns
 the bridge's address and filters it makes it unavailable for both of them.
+Also, delegating known bridges to members of your social network can be
+dangerous: an the adversary who can learn who knows which bridges may
+be able to reconstruct the social network.
 
 Note that a central set of bridge directory authorities can still be
 compatible with a decentralized discovery process. That is, how users
@@ -798,7 +829,7 @@ reach the bridge authority. We address these concerns next.
 Because the blocked users are running our software too, we have many
 opportunities to improve usability or robustness. Our second design builds
 on the first by encouraging volunteers to run several bridges at once
-(or coordinate with other bridge volunteers), such that some fraction
+(or coordinate with other bridge volunteers), such that some
 of the bridges are likely to be available at any given time.
 
 The blocked user's Tor client would periodically fetch an updated set of
@@ -813,73 +844,64 @@ the available bridges, and also mirrored at each bridge.
 
 What about people who want to volunteer as bridges but don't know any
 suitable blocked users? What about people who are blocked but don't
-know anybody on the outside? Here we describe a way to make use of these
+know anybody on the outside? Here we describe how to make use of these
 \emph{public bridges} in a way that still makes it hard for the attacker
 to learn all of them.
 
-The basic idea is to divide public bridges into a set of buckets based on
-identity key, where each bucket has a different policy for distributing
-its bridge addresses to users. Each of these \emph{distribution policies}
+The basic idea is to divide public bridges into a set of pools based on
+identity key. Each pool corresponds to a \emph{distribution strategy}:
+an approach to distributing its bridge addresses to users. Each strategy
 is designed to exercise a different scarce resource or property of
 the user.
 
-How do we divide bridges into buckets such that they're evenly distributed
-and the allocation is hard to influence or predict, but also in a way
-that's amenable to creating more buckets later on without reshuffling
-all the bridges? We compute the bucket for a given bridge by hashing the
-bridge's identity key along with a secret that only the bridge authority
-knows: the first $n$ bits of this hash dictate the bucket number,
-where $n$ is a parameter that describes how many buckets we want at this
-point. We choose $n=3$ to start, so we have 8 buckets available; but as
-we later invent new distribution policies, we can increment $n$ to split
-the 8 into 16 buckets. Since a bridge can't predict the next bit in its
-hash, it can't anticipate which identity key will correspond to a certain
-bucket when the buckets are split. Further, since the bridge authority
-doesn't provide any feedback to the bridge about which bucket it's in,
-an adversary signing up bridges to fill a certain bucket will be slowed.
-
-% This algorithm is not ideal. When we split buckets, each existing
-% bucket is cut in half, where half the bridges remain with the
+How do we divide bridges between these strategy pools such that they're
+evenly distributed and the allocation is hard to influence or predict,
+but also in a way that's amenable to creating more strategies later
+on without reshuffling all the pools? We assign a given bridge
+to a strategy pool by hashing the bridge's identity key along with a
+secret that only the bridge authority knows: the first $n$ bits of this
+hash dictate the strategy pool number, where $n$ is a parameter that
+describes how many strategy pools we want at this point. We choose $n=3$
+to start, so we divide bridges between 8 pools; but as we later invent
+new distribution strategies, we can increment $n$ to split the 8 into
+16. Since a bridge can't predict the next bit in its hash, it can't
+anticipate which identity key will correspond to a certain new pool
+when the pools are split. Further, since the bridge authority doesn't
+provide any feedback to the bridge about which strategy pool it's in,
+an adversary who signs up bridges with the goal of filling a certain
+pool~\cite{casc-rep} will be hindered.
+
+% This algorithm is not ideal. When we split pools, each existing
+% pool is cut in half, where half the bridges remain with the
 % old distribution policy, and half will be under what the new one
 % is. So the new distribution policy inherits a bunch of blocked
 % bridges if the old policy was too loose, or a bunch of unblocked
 % bridges if its policy was still secure. -RD
 %
-%
-% Having talked to Roger on the phone, I realized that the following
-% paragraph was based on completely misunderstanding ``bucket'' as
-% used here. But as per his request, I'm leaving it in in case it
-% guides rewording so that equally careless readers are less likely
-% to go astray. -PFS
-%
-% I don't understand this adversary. Why do we care if an adversary
-% fills a particular bucket if bridge requests are returned from
-% random buckets? Put another way, bridge requests _should_ be returned
-% from unpredictable buckets because we want to be resilient against
-% whatever optimal distribution of adversary bridges an adversary manages
-% to arrange. (Cf. casc-rep) I think it should be more chordlike. 
+% I think it should be more chordlike.
 % Bridges are allocated to wherever on the ring which is divided
 % into arcs (buckets).
 % If a bucket gets too full, you can just split it.
 % More on this below. -PFS
 
-The first distribution policy (used for the first bucket) publishes bridge
+The first distribution strategy (used for the first pool) publishes bridge
 addresses in a time-release fashion. The bridge authority divides the
-available bridges into partitions which are deterministically available
-only in certain time windows. That is, over the course of a given time
-slot (say, an hour), each requestor is given a random bridge from within
-that partition. When the next time slot arrives, a new set of bridges
-are available for discovery. Thus a bridge is always available when a new
+available bridges into partitions, and each partition is deterministically
+available only in certain time windows. That is, over the course of a
+given time slot (say, an hour), each requestor is given a random bridge
+from within that partition. When the next time slot arrives, a new set
+of bridges from the pool are available for discovery. Thus some bridge
+address is always available when a new
 user arrives, but to learn about all bridges the attacker needs to fetch
-the new addresses at every new time slot. By varying the length of the
+all new addresses at every new time slot. By varying the length of the
 time slots, we can make it harder for the attacker to guess when to check
 back. We expect these bridges will be the first to be blocked, but they'll
 help the system bootstrap until they \emph{do} get blocked. Further,
 remember that we're dealing with different blocking regimes around the
 world that will progress at different rates---so this bucket will still
-be useful to some users even as the arms race progresses.
+be useful to some users even as the arms races progress.
 
-The second distribution policy publishes bridge addresses based on the IP
+The second distribution strategy publishes bridge addresses based on the IP
 address of the requesting user. Specifically, the bridge authority will
 divide the available bridges in the bucket into a bunch of partitions
 (as in the first distribution scheme), hash the requestor's IP address
@@ -887,23 +909,30 @@ with a secret of its own (as in the above allocation scheme for creating
 buckets), and give the requestor a random bridge from the appropriate
 partition. To raise the bar, we should discard the last octet of the
 IP address before inputting it to the hash function, so an attacker
-who only controls a ``/24'' address only counts as one user. A large
-attacker like China will still be able to control many addresses, but
-the hassle of needing to establish connections from each network (or
-spoof TCP connections) may still slow them down. (We could also imagine
-a policy that combines the time-based and location-based policies to
-further constrain and rate-limit the available bridge addresses.)
-
-The third policy is based on Circumventor's discovery strategy. Realizing
-that its adoption will remain limited without some central coordination
-mechanism, the Circumventor project has started a mailing list to
+who only controls a single ``/24'' network only counts as one user. A
+large attacker like China will still be able to control many addresses,
+but the hassle of establishing connections from each network (or spoofing
+TCP connections) may still slow them down. Similarly, as a special case,
+we should treat IP addresses that are Tor exit nodes as all being on
+the same network.
+
+The third strategy combines the time-based and location-based
+strategies to further constrain and rate-limit the available bridge
+addresses. Specifically, the bridge address provided in a given time
+slot to a given network location is deterministic within the partition,
+rather than chosen randomly each time from the partition. Thus, repeated
+requests during that time slot from a given network are given the same
+bridge address as the first request.
+
+The fourth strategy is based on Circumventor's discovery strategy.
+The Circumventor project, realizing that its adoption will remain limited
+if it has no central coordination mechanism, has started a mailing list to
 distribute new proxy addresses every few days. From experimentation it
 seems they have concluded that sending updates every three or four days
-is sufficient to stay ahead of the current attackers. We could give out
-bridge addresses from the third bucket in a similar fashion
+is sufficient to stay ahead of the current attackers.
 
-The fourth policy provides an alternative approach to a mailing list:
-users provide an email address, and receive an automated response
+The fifth strategy provides an alternative approach to a mailing list:
+users provide an email address and receive an automated response
 listing an available bridge address. We could limit one response per
 email address. To further rate limit queries, we could require a CAPTCHA
 solution~\cite{captcha} in each case too. In fact, we wouldn't need to
@@ -911,152 +940,43 @@ implement the CAPTCHA on our side: if we only deliver bridge addresses
 to Yahoo or GMail addresses, we can leverage the rate-limiting schemes
 that other parties already impose for account creation.
 
-The fifth policy ties in
-...
-reputation system
-Pick some seeds---trusted people in the blocked area---and give
-them each a few hundred bridge addresses. Run a website next to the
-bridge authority, where they can log in (they only need persistent
-pseudonyms). Give them tokens slowly over time. They can use these
-tokens to delegate trust to other people they know. The tokens can
-be exchanged for new accounts on the website.
-Accounts in ``good standing'' accrue new bridge addresses and new
-tokens.
-This is great, except how do we decide that an account is in good
-standing? One answer is to measure based on whether the bridge addresses
-we give it end up blocked. But how do we decide if they get blocked?
-Other questions below too.
-\ref{sec:accounts}
-
-Buckets six through eight are held in reserve, in case our currently
-deployed tricks all fail at once---so we can adapt and move to
-new approaches quickly, and have some bridges available for the new
-schemes. (Bridges that sign up and don't get used yet may be unhappy that
-they're not being used; but this is a transient problem: if bridges are
-on by default, nobody will mind not being used yet.)
-
-
-\subsubsection{Public Bridges with Coordinated Discovery}
-
-****Pretty much this whole subsubsection will probably need to be
-deferred until ``later'' and moved to after end document, but I'm leaving
-it here for now in case useful.******
-
-Rather than be entirely centralized, we can have a coordinated
-collection of bridge authorities, analogous to how Tor network
-directory authorities now work.
-
-Key components
-``Authorities'' will distribute caches of what they know to overlapping
-collections of nodes so that no one node is owned by one authority.
-Also so that it is impossible to DoS info maintained by one authority
-simply by making requests to it.
-
-Where a bridge gets assigned is not predictable by the bridge?
-
-If authorities don't know the IP addresses of the bridges they
-are responsible for, they can't abuse that info (or be attacked for
-having it). But, they also can't, e.g., control being sent massive
-lists of nodes that were never good. This raises another question.
-We generally decry use of IP address for location, etc. but we
-need to do that to limit the introduction of functional but useless
-IP addresses because, e.g., they are in China and the adversary
-owns massive chunks of the IP space there.
-
-We don't want an arbitrary someone to be able to contact the
-authorities and say an IP address is bad because it would be easy
-for an adversary to take down all the suspicious bridges
-even if they provide good cover websites, etc. Only the bridge
-itself and/or the directory authority can declare a bridge blocked
-from somewhere.
-
-
-9. Bridge directories must not simply be a handful of nodes that
-provide the list of bridges. They must flood or otherwise distribute
-information out to other Tor nodes as mirrors. That way it becomes
-difficult for censors to flood the bridge directory servers with
-requests, effectively denying access for others. But, there's lots of
-churn and a much larger size than Tor directories.  We are forced to
-handle the directory scaling problem here much sooner than for the
-network in general. Authorities can pass their bridge directories
-(and policy info) to some moderate number of unidentified Tor nodes.
-Anyone contacting one of those nodes can get bridge info. the nodes
-must remain somewhat synched to prevent the adversary from abusing,
-e.g., a timed release policy or the distribution to those nodes must
-be resilient even if they are not coordinating.
-
-I think some kind of DHT like scheme would work here. A Tor node is
-assigned a chunk of the directory.  Lookups in the directory should be
-via hashes of keys (fingerprints) and that should determine the Tor
-nodes responsible. Ordinary directories can publish lists of Tor nodes
-responsible for fingerprint ranges.  Clients looking to update info on
-some bridge will make a Tor connection to one of the nodes responsible
-for that address.  Instead of shutting down a circuit after getting
-info on one address, extend it to another that is responsible for that
-address (the node from which you are extending knows you are doing so
-anyway). Keep going.  This way you can amortize the Tor connection.
-
-10. We need some way to give new identity keys out to those who need
-them without letting those get immediately blocked by authorities. One
-way is to give a fingerprint that gets you more fingerprints, as
-already described. These are meted out/updated periodically but allow
-us to keep track of which sources are compromised: if a distribution
-fingerprint repeatedly leads to quickly blocked bridges, it should be
-suspect, dropped, etc. Since we're using hashes, there shouldn't be a
-correlation with bridge directory mirrors, bridges, portions of the
-network observed, etc. It should just be that the authorities know
-about that key that leads to new addresses.
+The sixth strategy ties in the social network design with public
+bridges and a reputation system. We pick some seeds---trusted people in
+blocked areas---and give them each a few dozen bridge addresses and a few
+\emph{delegation tokens}. We run a website next to the bridge authority,
+where the seeds can log in (they can log in via Tor, and they don't need
+to provide actual identities, just persistent pseudonyms). The seeds can
+delegate trust to other people they know by giving them a token. The
+tokens can be exchanged for new accounts on the website. Accounts in
+``good standing'' then accrue new bridge addresses and new tokens.
+As usual, reputation schemes bring in a host of new complexities
+(for example, how do we decide that an account is in good
+standing?), so we put off deeper discussion of the social network
+reputation strategy for Section\ref{sec:accounts}.
+
+Pools seven and eight are held in reserve, in case our currently deployed
+tricks all fail at once and the adversary blocks all those bridges---so
+we can adapt and move to new approaches quickly, and have some bridges
+immediately available for the new schemes. New strategies might be based
+on some other scarce resource, such as relaying traffic for others or
+other proof of energy spent. (We might also worry about the incentives
+for bridges that sign up and get allocated to the reserve pools: will they
+be unhappy that they're not being used? But this is a transient problem:
+if Tor users are bridges by default, nobody will mind not being used yet.
+See also Section~\ref{subsec:incentives}.)
+
+%Is it useful to load balance which bridges are handed out? The above
+%bucket concept makes some bridges wildly popular and others less so.
+%But I guess that's the point.
+
+\subsection{Public bridges with coordinated discovery}
+
+We presented the above discovery strategies in the context of a single
+bridge directory authority, but in practice we will want to distribute
+the operations over several bridge authorities---a single point of
+failure or attack is a bad move.
 
-This last point is very much like the issues in the valet nodes paper,
-which is essentially about blocking resistance wrt exiting the Tor network,
-while this paper is concerned with blocking the entering to the Tor network.
-In fact the tickets used to connect to the IPo (Introduction Point),
-could serve as an example, except that instead of authorizing
-a connection to the Hidden Service, it's authorizing the downloading
-of more fingerprints.
-
-Also, the fingerprints can follow the hash(q + '1' + cookie) scheme of
-that paper (where q = hash(PK + salt) gave the q.onion address).  This
-allows us to control and track which fingerprint was causing problems.
-
-Note that, unlike many settings, the reputation problem should not be
-hard here. If a bridge says it is blocked, then it might as well be.
-If an adversary can say that the bridge is blocked wrt
-$\mathit{censor}_i$, then it might as well be, since
-$\mathit{censor}_i$ can presumably then block that bridge if it so
-chooses.
-
-11. How much damage can the adversary do by running nodes in the Tor
-network and watching for bridge nodes connecting to it?  (This is
-analogous to an Introduction Point watching for Valet Nodes connecting
-to it.) What percentage of the network do you need to own to do how
-much damage. Here the entry-guard design comes in helpfully.  So we
-need to have bridges use entry-guards, but (cf. 3 above) not use
-bridges as entry-guards. Here's a serious tradeoff (again akin to the
-ratio of valets to IPos) the more bridges/client the worse the
-anonymity of that client. The fewer bridges/client the worse the 
-blocking resistance of that client.
-
-
-\subsubsection{Bootstrapping: finding your first bridge.}
-\label{subsec:first-bridge}
-How do users find their first public bridge, so they can reach the
-bridge authority to learn more?
-Most government firewalls are not perfect. That is, they allow connections to
-Google cache or some open proxy servers, or they let file-sharing traffic or
-Skype or World-of-Warcraft connections through. We assume that the
-users have some mechanism for bypassing the firewall initially.
-For users who can't use any of these techniques, hopefully they know
-a friend who can---for example, perhaps the friend already knows some
-bridge relay addresses.
-(If they can't get around it at all, then we can't help them---they
-should go meet more people.)
-
-Is it useful to load balance which bridges are handed out? The above
-bucket concept makes some bridges wildly popular and others less so.
-But I guess that's the point.
-
-Families of bridges: give out 4 or 8 at once, bound together.
+...
 
 \subsection{Advantages of deploying all solutions at once}
 
@@ -1064,36 +984,28 @@ For once we're not in the position of the defender: we don't have to
 defend against every possible filtering scheme, we just have to defend
 against at least one.
 
+adversary has to guess how to allocate his resources
 
+(nick, want to write this section?)
 
-\subsection{Remaining unsorted notes}
-
-In the first subsection we describe how to find a first bridge.
-
-Thus they can reach the BDA. From here we either assume a social
-network or other mechanism for learning IP:dirport or key fingerprints
-as above, or we assume an account server that allows us to limit the
-number of new bridge relays an external attacker can discover.
-
-Going to be an arms race. Need a bag of tricks. Hard to say
-which ones will work. Don't spend them all at once.
-
-Some techniques are sufficient to get us an IP address and a port,
-and others can get us IP:port:key. Lay out some plausible options
-for how users can bootstrap into learning their first bridge.
-
-attack: adversary can reconstruct your social network by learning who
-knows which bridges.
-
-
+%\subsection{Remaining unsorted notes}
 
+%In the first subsection we describe how to find a first bridge.
 
+%Going to be an arms race. Need a bag of tricks. Hard to say
+%which ones will work. Don't spend them all at once.
 
+%Some techniques are sufficient to get us an IP address and a port,
+%and others can get us IP:port:key. Lay out some plausible options
+%for how users can bootstrap into learning their first bridge.
 
 %\section{The account / reputation system}
 \section{Social networks with directory-side support}
 \label{sec:accounts}
 
+One answer is to measure based on whether the bridge addresses
+we give it end up blocked. But how do we decide if they get blocked?
+
 Perhaps each bridge should be known by a single bridge directory
 authority. This makes it easier to trace which users have learned about
 it, so easier to blame or reward. It also makes things more brittle,
@@ -1191,8 +1103,7 @@ if the restrictive firewall pushes up the number of Tor users, then the
 
 Hard to say which of these pressures will ultimately win out.
 
-...
-% Nick can rewrite/elaborate on this section?
+Nick, want to rewrite/elaborate on this section?
 
 \subsection{Observers can tell who is publishing and who is reading}
 \label{subsec:upload-padding}
@@ -1323,6 +1234,8 @@ The related question is: if the bridge relays change IP addresses
 periodically, how often does the bridge user need to "check in" in order
 to keep from being cut out of the loop?
 
+Families of bridges: give out 4 or 8 at once, bound together.
+
 \subsection{Cablemodem users don't provide important websites}
 \label{subsec:block-cable}
 
@@ -1375,6 +1288,7 @@ case were it not a bridge).
 
 
 \subsection{How to motivate people to run bridge relays}
+\label{subsec:incentives}
 
 One of the traditional ways to get people to run software that benefits
 others is to give them motivation to install it themselves.  An often
@@ -1392,6 +1306,9 @@ implications, but hey.) (In many cases there won't be much activity,
 so this may backfire. Or it may be better suited to full-fledged Tor
 servers.)
 
+% Also consider everybody-a-server. Many of the scalability questions
+% are easier when you're talking about making everybody a bridge.
+
 \subsection{What if the clients can't install software?}
 
 [this section should probably move to the related work section,
@@ -1497,9 +1414,108 @@ should be 4 or 8 depends on our churn.
 the account server. let's call it a database, it doesn't have to
 be a thing that human interacts with.
 
-rate limiting mechanisms:
-energy spent. captchas. relaying traffic for others?
-send us \$10, we'll give you an account
-
 so how do we reward people for being good?
 
+\subsubsection{Public Bridges with Coordinated Discovery}
+
+****Pretty much this whole subsubsection will probably need to be
+deferred until ``later'' and moved to after end document, but I'm leaving
+it here for now in case useful.******
+
+Rather than be entirely centralized, we can have a coordinated
+collection of bridge authorities, analogous to how Tor network
+directory authorities now work.
+
+Key components
+``Authorities'' will distribute caches of what they know to overlapping
+collections of nodes so that no one node is owned by one authority.
+Also so that it is impossible to DoS info maintained by one authority
+simply by making requests to it.
+
+Where a bridge gets assigned is not predictable by the bridge?
+
+If authorities don't know the IP addresses of the bridges they
+are responsible for, they can't abuse that info (or be attacked for
+having it). But, they also can't, e.g., control being sent massive
+lists of nodes that were never good. This raises another question.
+We generally decry use of IP address for location, etc. but we
+need to do that to limit the introduction of functional but useless
+IP addresses because, e.g., they are in China and the adversary
+owns massive chunks of the IP space there.
+
+We don't want an arbitrary someone to be able to contact the
+authorities and say an IP address is bad because it would be easy
+for an adversary to take down all the suspicious bridges
+even if they provide good cover websites, etc. Only the bridge
+itself and/or the directory authority can declare a bridge blocked
+from somewhere.
+
+
+9. Bridge directories must not simply be a handful of nodes that
+provide the list of bridges. They must flood or otherwise distribute
+information out to other Tor nodes as mirrors. That way it becomes
+difficult for censors to flood the bridge directory servers with
+requests, effectively denying access for others. But, there's lots of
+churn and a much larger size than Tor directories.  We are forced to
+handle the directory scaling problem here much sooner than for the
+network in general. Authorities can pass their bridge directories
+(and policy info) to some moderate number of unidentified Tor nodes.
+Anyone contacting one of those nodes can get bridge info. the nodes
+must remain somewhat synched to prevent the adversary from abusing,
+e.g., a timed release policy or the distribution to those nodes must
+be resilient even if they are not coordinating.
+
+I think some kind of DHT like scheme would work here. A Tor node is
+assigned a chunk of the directory.  Lookups in the directory should be
+via hashes of keys (fingerprints) and that should determine the Tor
+nodes responsible. Ordinary directories can publish lists of Tor nodes
+responsible for fingerprint ranges.  Clients looking to update info on
+some bridge will make a Tor connection to one of the nodes responsible
+for that address.  Instead of shutting down a circuit after getting
+info on one address, extend it to another that is responsible for that
+address (the node from which you are extending knows you are doing so
+anyway). Keep going.  This way you can amortize the Tor connection.
+
+10. We need some way to give new identity keys out to those who need
+them without letting those get immediately blocked by authorities. One
+way is to give a fingerprint that gets you more fingerprints, as
+already described. These are meted out/updated periodically but allow
+us to keep track of which sources are compromised: if a distribution
+fingerprint repeatedly leads to quickly blocked bridges, it should be
+suspect, dropped, etc. Since we're using hashes, there shouldn't be a
+correlation with bridge directory mirrors, bridges, portions of the
+network observed, etc. It should just be that the authorities know
+about that key that leads to new addresses.
+
+This last point is very much like the issues in the valet nodes paper,
+which is essentially about blocking resistance wrt exiting the Tor network,
+while this paper is concerned with blocking the entering to the Tor network.
+In fact the tickets used to connect to the IPo (Introduction Point),
+could serve as an example, except that instead of authorizing
+a connection to the Hidden Service, it's authorizing the downloading
+of more fingerprints.
+
+Also, the fingerprints can follow the hash(q + '1' + cookie) scheme of
+that paper (where q = hash(PK + salt) gave the q.onion address).  This
+allows us to control and track which fingerprint was causing problems.
+
+Note that, unlike many settings, the reputation problem should not be
+hard here. If a bridge says it is blocked, then it might as well be.
+If an adversary can say that the bridge is blocked wrt
+$\mathit{censor}_i$, then it might as well be, since
+$\mathit{censor}_i$ can presumably then block that bridge if it so
+chooses.
+
+11. How much damage can the adversary do by running nodes in the Tor
+network and watching for bridge nodes connecting to it?  (This is
+analogous to an Introduction Point watching for Valet Nodes connecting
+to it.) What percentage of the network do you need to own to do how
+much damage. Here the entry-guard design comes in helpfully.  So we
+need to have bridges use entry-guards, but (cf. 3 above) not use
+bridges as entry-guards. Here's a serious tradeoff (again akin to the
+ratio of valets to IPos) the more bridges/client the worse the
+anonymity of that client. The fewer bridges/client the worse the 
+blocking resistance of that client.
+
+
+