Re: [Mixmaster-devel] Inter-remailer protocol
Brought to you by:
weaselp
From: Katherine <ka...@th...> - 2001-11-15 02:48:26
|
On Wed, 14 Nov 2001, Len Sassaman wrote: > Actually, putting the port number that the remailer is listening on in the > cap string would be a nice feature, I think. Yeah, would seem to be required, really, if remailers will be able to automatically start sending to new remailers. > This is good, as we've previously stated -- though I want to do batching. > Put all messages from a given time period, plus noise, into a bundle and > transmit that at once. Should we support both? I personally think batch jobs will be best, but that's just my opinion. I've been wrong on occassion :) > We definately want to revert to SMTP at some point. Should we have a > discussion on what should trigger that? After n tries, where n is defined by the remop? Say, if it fails 3 times or whatever go ahead and email the messages; also maybe alert the remop that sending to remailer X didn't work out. > What happens if a message bundle is interrupted during transmission? It should be resent, silly :) There should be some sort of confirmation that the message was received. Perhaps something like this: Client takes a bundle of messages, and splits the bundle into, say, 5 parts. Send the first part, marked "1/5", then "2/5", so on. After it receives each part, the server replies with a hash of what it received. If it's correct the client sends the next part; otherwise resend. The x/n part tells the server the order and if something is being resent. Could even do something like, if the same part is sent a certain number of times, give up and try again later. [snip] > > - only the server is authenticated; the client is anonymous > > Authenticating the client won't really do much to solve spam attacks. I'm > inclined to leave this as it is. For the most part, yes. But there may be a case where the remailer only wants to talk to other remailers. I don't know if it's worth the trouble; perhaps later? > > - bit-bucket attack: the proof-of-possession challenges (e.g., > > E_k(rnd_c)) don't work since the recipient of the challenge can > > return the opaque string provided by the server -- this allows an > > active attacker to spoof any server without detection by the > > client; although he can't read the messages, he can throw them > > into the bit-bucket. This could be prevented by verifying that > > the response string differs from the challenge string. > > > > - truncation attack: the message length and message hash (in the > > Message msg, step 8) are unprotected -- this allows an active > > attacker modify each (at a minimum it seems the attacker can > > reduce the message length to zero without detection by either > > party) > > Thoughts on these two? To clarify for someone not overly familar with mix (namely, me): THis seems to be an overall problem with mix? Kat |