attacks and cleanups on the bridge disbursement plans

svn:r12720

1 files changed, 46 insertions, 7 deletions

diff --git a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
index 34decd6e9..03262535f 100644
--- a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
+++ b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
@@ -45,9 +45,38 @@ IP-based.
      where PS is the start of the currrent period.  Send
      the first K bridges in the ring after point X.
 
+     [If we want to make sure that repeat queries are given exactly the
+      same results, then we can't let the ring change during the
+      time period. For a long time period like a month, that's quite a
+      hassle. How about instead just keeping a replay cache of addresses
+      that have been answered, and sending them a "sorry, you already got
+      your addresses for the time period; perhaps you should try these
+      other fine distribution strategies while you wait?" response? This
+      approach would also resolve the "Make sure you can't construct a
+      distinct address to match an existing one" note below. -RD]
+
+     [While we're at it, if we do the replay cache thing and don't need
+      repeatable answers, we could just pick K random answers from the
+      pool. Is it beneficial that a bridge user who knows about a clump of
+      nodes will be sharing them with other users who know about a similar
+      (overlapping) clump? One good aspect is against an adversary who
+      learns about a clump this way and watches those bridges to learn
+      other users and discover *their* bridges: he doesn't learn about
+      as many new bridges as he might if they were randomly distributed.
+      A drawback is against an adversary who happens to pick two email
+      addresses in P that include overlapping answers: he can measure
+      the difference in clumps and estimate how quickly the bridge pool
+      is growing. -RD]
+
+     [If we make the period P be mailbox-specific, and make it a random
+      value around some mean, then we make it harder for an attacker to
+      know when to try using his small army of gmail addresses to gather
+      another harvest. But we also make it harder for users to know when
+      they can try again. -RD]
+
   To normalize an email address:
      Start with the RFC822 address.  Consider only the mailbox {???}
-     portion of the address (username@host).  Put this into lowercase
+     portion of the address (username@domain).  Put this into lowercase
      ascii.
 
   Questions:
@@ -65,8 +94,7 @@ IP-based.
      bridges nickm@X got (or would get).
 
      Make sure that we actually check headers so we can't be trivially
-     used to sapam people.
-
+     used to spam people.
 
 
 2. IP-based.
@@ -86,11 +114,11 @@ IP-based.
 
   Setup: using an AS map or a geoip map or some other flawed input
   source, divide IP space into "areas" such that surveying a large
-  collection of "areas" is hard.  For v0, use /24 adress blocks.
+  collection of "areas" is hard.  For v0, use /24 address blocks.
 
   Group areas into N_C clusters.
 
-  Generate nonces L, M, N.
+  Generate secrets L, M, N.
 
   Set the period P such that P*(bridges-per-cluster/K) = T_flush.
   Don't set P to greater than a week, or less than three hours.
@@ -100,14 +128,25 @@ IP-based.
      Based on HMAC(L,ID), assign the bridge to a cluster.  Within each
      cluster, keep the bridges in a ring based on HMAC(M,ID).
 
+     [Should we re-sort the rings for each new time period, so the ring
+      for a given cluster is based on HMAC(M,PS|ID)? -RD]
+
   When we get a connection:
 
      If it's http, redirect it to https.
 
-     Let net be the incoming IP network.  Let PS be the current
-     period.  Compute X = HMAC(N, PS|net).  Return the next K bridges
+     Let area be the incoming IP network.  Let PS be the current
+     period.  Compute X = HMAC(N, PS|area).  Return the next K bridges
      in the ring after X.
 
+     [Don't we want to compute C = HMAC(key, area) to learn what cluster
+     to answer from, and then X = HMAC(key, PS|area) to pick a point in
+     that ring? -RD]
+
+  Need to clarify that some HMACs are for rings, and some are for
+  partitions. How rings scale is clear. How do we grow the number of
+  partitions? Looking at successive bits from the HMAC output is one way.
+
 3. Open issues
 
    Denial of service attacks