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$
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 ... 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. 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. Third, as said above, it is only available in trunk, not in a live build. 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. 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. 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), not resuming SSK inserts, not resuming requests, thread madness, plugin interface confusion, ... 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 ... Fix it right away or it will be postponed forever. 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. But it still doesn't make the result any better. Sorry for this rant but I do get frustrated over such things, given enough time. :| -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070806/632a8c83/attachment.pgp>
