[Freenetmail-devel] RE: Freemail lives

[Adam T. <tho...@ug...>]

Good to hear from you.  No worries about contributing; I realize you're
still working.  Any help at any point is appreciated.

The "agreed-key" protocol is specified at
http://freenetmail.sourceforge.net/docs/specification.html#known-locatio
n.  Just an inadvertent renaming in the email.

As for message redundancy, I've been leaving that up to Freenet and the
user for now.  Doing a TCP-type thing will require a lot more complexity
(since just reinserting under the same key isn't useful as your node
already has the key, you need to insert someplace else, and the other
party needs to know where that is, etc.), but it's possible.  Basically
I just figure that if you send somebody a request and don't ever get a
receipt, you can send them another fresh request.  I'm reluctant to
automate the resending since that could be trivially used as a flooding
tool, intentional or not.  Keep in mind that the semantics of refusing a
request are (currently) equivalent to having not received the request.
This means that a stubborn requester who thinks his requests aren't
getting through will essentially be DoS'ing a requestee who simply
doesn't want to talk to him.  While allowing/encouraing/forcing a
requestee to send a negative reply to a request would solve the problem
in the innocent case, it greatly exaccerbates the damage caused by an
intentional DoS attack, since the requestee has to formulate and publish
a response to each request he refuses.  Making such a negative reply an
option for the requestee might be a good compromise.

On a broader scale, the anonymous-introduction problem is still
generally intractable.  So while anything we can do to facilitate it is
good, I suppose my ultimate response would be that "you get what you pay
for" in terms of reliability vs. anonymity.  If you're absolutely
unwilling to use some other method of notifying and interesting the
requestee in your request, you simply won't get complete reliability.
Competition with attackers--or equivalently, a flood of genuine
requesters--makes that impossible.  At least, that's the conclusion I've
come to.  If anyone has a better solution, I'd love to discuss it.

Adam

> -----Original Message-----
> From: Xiaoliang (David) Wei [mailto:we...@ca...] 
> Sent: Saturday, July 27, 2002 2:13 AM
> To: Adam Thomason; Daniel M. Zimmerman; Joseph Kiniry
> Subject: Re: Freemail lives
> 
> 
> Hi Adam,
>      Sorry that I reply so late -- I've been crazily busy on 
> a project of Gigabit TCP. The first part of it is supposed to 
> be finished in the summer. After that, I am willing to help.
>      What do you mean by "agreed-key transmission protocols"? 
>  Also, about the dynamic window, is there any problem in the 
> timeouts when the attempts of contact fails? I've been 
> thinking about that. Roughly, I guess it may be similar to 
> the mechanism in TCP -- we have to implement some reliable 
> protocol on unreliable bases.
>       I will subscribe the maillist and keep an eye on it.
>       Thank you:)
> 
> -David
> 
> 
> Xiaoliang (David) Wei             Graduate Student in CS@Caltech
> http://www.cs.caltech.edu/~weixl 
> ====================================================
> ----- Original Message -----
> From: "Adam Thomason" <tho...@ug...>
> To: "David Wei" <we...@ca...>; "Daniel M. Zimmerman" 
> <dm...@cs...>; "Joseph Kiniry" <ki...@cs...>
> Sent: Wednesday, July 24, 2002 1:29 AM
> Subject: Freemail lives
> 
> 
> > Hey folks-
> >
> > It probably seemed like Freemail went extinct, but in fact 
> I've just 
> > been working outside of CVS since the satellite "broadband" I'm 
> > currently using has terrible latency.  I've just checked in 
> what I've 
> > been working on the past few weeks, which is a vast 
> improvement on the 
> > previous code.  I used a bit of the encryption stuff, but otherwise 
> > put together an entirely different system.  Here's a list 
> of the major
> > points:
> >
> > o Much improved protocol
> >   - Bidirectional channels established in one request + one receipt
> >   - Unified channel initiation request message type
> >   - Four request transmission methods (none requiring a 
> secure channel)
> >     + Fixed-window
> >     + Dynamic-window
> >     + External transmission
> >     + Agreed-upon key in Freenet
> > o Improved encryption
> >   - Negotiation messages use DH and 3DES, mail messages use 
> Blowfish o 
> > Swing GUI o SMTP and POP3 proxies o All new FCP library
> >   - Asynchronous FCP request manager
> > o Base16 encoding replaced with Base64; saves 33% bandwidth
> > o Improved logging
> >   - Debug classes replaced with J2v1.4 LogManager and Loggers o 
> > Improved exception handling
> >   - Pervasive use of J2v1.4 exception chaining
> >
> > So far the fixed-window protocol works completely, and the 
> only thing 
> > preventing the dynamic-window protocol from working is an 
> insert into 
> > Freenet of the window pointer.  Another couple menu items 
> are all that 
> > is missing from the external and agreed-key transmission 
> protocols, as 
> > well.  I've also updated the specification document and 
> checked that 
> > in.
> >
> > If anybody's still interested in contributing, comments, 
> bug reports, 
> > or code would be great.  This is still a very unstable 
> release, but I 
> > just wanted to get something into CVS.  Once I'm reasonably 
> satisfied 
> > with its stability I'll build a file release on SF and 
> announce it on 
> > a Freenet list.
> >
> > Hope your summers are going well,
> > Adam
> >
> > P.S. If you're interested in further developments, I'll be 
> posting to 
> > fre...@li... from now on.
> >
> > --
> > Adam Thomason
> > tho...@ug...
> >
> >
> >
> 
>