* Matthew Toseland <toad at amphibian.dyndns.org> [2007-08-06 22:28:30]:
> FROM FROST: > > On Wednesday 01 August 2007 21:23, NextGen$ wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-07-26 20:01:34]: > > > On Thursday 26 July 2007 04:14, NextGen$ wrote: > > > > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-07-25 18:39:11]: > > > > > I propose that darknet nodes be allowed to forward announcements and > > > > > path folding messages (ConnectDestination etc), without including > > > > > their own noderefs. > > > > > > > > > > Any objections? > > > > > > > > _o/ > > > > It's a bad idea. > > > > Be informed that my node wont behave that way... > > > > > > Why, precisely, is it a bad idea? As far as I can tell it doesn't > > > compromise the nodes which only relay and never send their own noderef? > > > > It makes flow analysis related attackes both trivial and more effective. > > > > I'm really dissapointed that you implemented it before leaving me time to > > respond. You did so even though I explained to you my concerns on IRC... > > > > I told you about an attack vector (flow analysis using request size - > > arguably already present but currently not easily exploitable) then we > > disccused about workarounds (padding noderefs, limitating the number of > > refs per request) and didn't manage to find any 'good' solution. > > > > Your implementation doesn't even feature basic workarounds we talked about > > and you have enabled that 'risky' option by default :( > > > > I don't mind about opennet beeing insecure but don't lower artificially the > > security level provided by darknet. > > > > NextGen$ > Let's reply in order : > First, what kind of flow attack do you mean and why is it currently not > exploitable but would be exploitable after that new feature? You know, such > stuff is somewhat interesting in networks like freenet, it doesn't hurt to > mention it publically. It might even make it simpler to find a solution you > know ... > Reading the thread will tell you about it... If you can't figure out the threat by yourself I doubt you can be of any help, sorry. > Second, "lower artificially the security level provided by darknet" is what > was done in the past to debug it, or due to time constraints, talking > about "this is alpha, bear with it until it gets removed/fixed in > months/years". I don't see the point why another temporary weakening is that > important to you. That one benefits only to opennet. > It may serve another purpose and that purpose may be less > important or perhaps the security issues are worse (how should I know?), but > contrary to the weakenings for debugging reasons it may actually get fixed in > reasonable time. There is even the chance of fixing it before releasing > another version. > Here we are talking about a 'feature' that isn't planned to be removed until opennet dies. > Third, as said above, it is only available in trunk, not in a live build. > Yeah, I said it... better to yell before the harm is done. > Forth, not making it the default would render it useless. How about > not "fixing" the problem by removing stuff for which you don't care, > crippling it or rendering it useless, but just fixing it completly, even if > that means waiting with another build for a week. Again, here we are talking about a feature which has inherent problems; not an implementation bug. > You know, given freenets history I would bet that else it will just be left > as > it is for months if not years, as everything that works somewhat. Hence reacting now is important. > Talk about link crypto that allows MITM and is DoSable (the first was fixed > after ~1 year iirc, the second is finally a SoC project after at least one > and a half years), Don't say that to me : I proposed to implement it last year! http://archives.freenetproject.org/message/20060503.130933.ccc20f47.en.html > not resuming SSK inserts, As far as I know that works and has been implemented a while ago. > not resuming requests, It gives a good incentive to users not to restart their node (helps limitating churn) hence I didn't try to implement it... others might have their reasons as well. > thread madness, I worked on that one... and have plans but no time to improve the situation even more. > plugin interface confusion, ... Toad was working on that one before opennet became 'the priority'... I won't do it : three different persons have been involved and now we have three different plugin systems. I wont do a fourth. > It all works somewhat, possibly not as well as it should, possibly not > helping/protecting as it should but it works in one way or another. Other > things seem more important, thus its left as it is. And left and left and ... I^we have a finite amount of time at our disposal, so we schedule according to priorities... Of course devs and users don't have the same views on what's important... Do it yourself or propose a bounty to someone if you really want something to be implemented in spite of its 'low priority'. > Fix it right away or it will be postponed forever. In that specific case it's 'revert toad's patch'. That feature is broken by design... there might be acceptable workarounds to mitigate its effects... but the main problem is that they haven't been discussed nor implemented. > Not to blame any dev for > that, simple time constraints and the resulting considerations will cause > that if it works, even if just somewhat, and time constraints are admittedly > a huge problem with freenets development. I wish it was a freenet-specific problem > But it still doesn't make the result any better. Ranting doesn't help either. Send patches ;) > Sorry for this rant but I do get frustrated over such things, given enough > time. :| Me too. NextGen$
