Re: [Mixmaster-devel] Inter-remailer protocol
Brought to you by:
weaselp
From: Michael T. S. <mi...@sh...> - 2001-12-10 02:02:28
|
Len Sassaman wrote: > As I've been discussing the inter-remailer protoco with people, two > other things have come up that hadn't been mentioned previously. > > One, we need to make sure it supports IPv6. (I'm sure there's no argument > there.) > > Two, I want to allow for a token/payment exchange in the protocol if it > could be easily provided. (Obviously nothing exists currently to utilize > that, but I'd like to allow for it in the future.) Aside from hashcash, there was a paper presented at USENIX regarding the use of client puzzles for TLS throttling. So, there are some working examples we can borrow from to add this into mix. I've started writing some stubs and backending work for mixmaster towards this end, but its far from complete. Regardless, here are my very rough notes from my TODO file so far on how it might work: TODO and notes: Client Puzzle support - Protocol - Mechanism to supply challenge keyspace to end users In the stats for the day? week? - Redundancy mechanism? What to do if your token gets old because the network is too slow? Should keying material be available longer than recommended total latency of network? What if the network gets flooded? Needs a sliding window on tokens and not just an arbitary cut off. Does the client puzzle need to be intra- remailer in a trusted remailer network? (ie, we can trust that all input nodes have client puzzles which we can test with our pinger, if they don't, they are not labled "client puzzle". Any remailer that is not listed as "client puzzle" that is remailing to a remailer that is a "client puzzle" remailer must provide a "client puzzle" in the form of a new header inside the next envelope of the mix message, just like ANY OTHER user of the remailer - which shouldn't cause any problems, because these headers are added by users. For remailers that are listed "client puzzle" and pass that test by issuing a "client puzzle" challenge or by dropping our NON-"client puzzle" pings. This is to prove that they do NOT work with NON-"client puzzle" hosts. These remailers are then trusted, and messages from them do not need to solve "client puzzles". New file: cp_remailers Explanation: Remailers that require Client Puzzles to process messages. Should be generated with a pinger that tests this suppostion to see if it is true, by supplying the opposite and affirmative cases. Optionally these remailers can be trusted and packets from them do not need to solve client puzzles. Cap String notes: cp - Client Puzzle only if the message is coming from a host (even a remailer) that does not generate Client Puzzle tokens. So, if you chain thru a remailer that does not have a cp in its caps string then you MUST generate a token for the remailer in the hop you are chaining thru. Good mix clients should do this for you automatically. Two or more cp remailers in a row, in a chain, and you only need to generate token for the first remailer. cpall - Client Puzzle from any host must be recieved. For a cpall remailer, every system that connects to it must generate a "Client Puzzle" token. Possible other cases: cppriority: Clients that generate client puzzles get priority on the server. All other mail is sent out only after cp mail is processed. One unsolved issue is nyms, how do they store enough tokens to handle reply messages? Maybe some form of "postage due" message sent to the nym account holder telling them they need to deposit N tokens to pick up their mail might work. If tokens are recieved in Y days, then the optionally gets dumped into the bit bucket or something. There is also the case of a client possibly needing to pay more to end point remailers than to middles, since the actual cost is higher for end points in terms of opportunity cost lost on abuse complaints. -- Michael T. Shinn PGPKey: 0x91C0781F GnuPG Key: BC626A27 |