Re: [Mixmaster-devel] Inter-remailer protocol
Brought to you by:
weaselp
From: Katherine <ka...@th...> - 2001-11-15 12:13:42
|
On Thu, 15 Nov 2001, Scott Renfro wrote: > > Yeah, would seem to be required, really, if remailers will be able to > > automatically start sending to new remailers. > > If you want stealth middlemen remailers, then I think we want to have: a > default port, an optional port specification in the capability strings, > and a syntax for specifying the port number in the mix headers. Some clarification: When I speak of "stealth remailers" I mean a remailer whose operator and location are unknown. I ran one called miranda for a time that was behind a nym, and all messages for it ended up in alt.anonymous.messages. Miranda had a known address but, theoretically, no one knew just where it was -- tracking messages led one to a newsgroup. I don't mean one that is unknown (ie unannounced). Not that the idea doesn't have appeal. However, considering that most remailers now limit the amount of messages from nonremailers (not to mention yell loudly when someone sends them what they deem to be too many messages) I don't think an unknown remailer could really do much. > The latter is important since the remailer transmitting to a stealth > remailer won't have any knowledge of the stealth remailer independent of > what is included in the mix headers. I think this can be as easy as > mi...@st...:22069. I do think this is a good idea. Not for the reason you listed, though :) The mix binary is for remailer operators and users; I think it would be neat to be able to have reply blocks that come back to you via this new protocol, not smtp. (but as you can't currently use mix in reply blocks that's a moot point; however it still has some uses, I think) > For stealth remailers, there may not be an SMTP route. At the risk of > complication, we might consider what all needs to be included in the mix > headers. Does this (whether or not there's a backup SMTP route for a > particular hop)? I don't really see it as a problem, personally. If there's no backup route, there's no backup route. Retry later or discard as unsendable. [snip attack descriptions] > > To clarify for someone not overly familar with mix (namely, me): THis > > seems to be an overall problem with mix? > > No, neither of these attacks should be possible under the new protocol. > The first attack allows an active attacker who does not control the > server to impersonate the server without the client's detection. The > second allows an active attacker to set the message length to zero > without either party's detection. Ok, I understand. Thanks Kat |