CDRv2 discussion (was: Re: Al-qaeda.net deprecated)

J.A. Terranson measl at mfn.org
Mon Jan 20 13:24:54 PST 2014


On Mon, 20 Jan 2014, Riad S. Wahby wrote:

> As far as I can tell this doesn't (yet) solve the problem of
> whitelisting subscribers to other nodes.
> 
> However, we can add one more step and solve this: when a node receives
> an email from the repeater whose sender is a member of the node's local
> subscriber list, it bounces the message back to the repeater with an
> added header saying, in effect, "I vouch for this sender."

There are two possible approaches to dealing with white (& black) 
listings:

(1) The repeater is a dumb one, and doesn't care, each node on the CDR is 
free to implement their own local rules and white/blacklists;

(2) Any one whitelist is agreed to be valid for all nodes: as you point 
out, there will need to be some way to recognize that.

Option 1 is simple to implement, but I don't know if it's consistent with 
the goals of sharing information freely amongst CDR subscribers. Option 2 
is, obviously, much harder to design.
 
<SNIP> 

\> I'm not totally in love with the master repeater scheme, though.
> Notwithstanding my previous comments regarding the supposed threat model
> behind the CDR's original conception, as long as we're paying the fixed
> cost of setting up a new system we may as well get *some* additional
> reliability out of it, right?

OK: if we want to design redundancy in all possible dimensions (above the 
threat model I believe, but still a good practice to have no single point 
of failure... We have a repeater on each CDR which, again, is elected 
every time an Elected Master Repeater refuses/fails to keep up with a 
heartbeat timer?
 
> -=rsw
> 


//Alif

-- 
Those who make peaceful change impossible,
make violent revolution inevitable.

An American Spring is coming:
   one way or another.






More information about the cypherpunks mailing list