What is wrong with the described advantages? Scenario:
board_1 and board_2 exists. An attacker tries to spam them to make the retrieval of messages nearly impossible. On board_1 he inserts 100 KSK keys with redirects to CHK keys that were randomly created and point to no existing content. The insert completes _very_ quickly. On board_2 he inserts 100 KSKs with random data behind it. The insert takes a _much_ longer time to complete. Now a Frost client updates this board. On board_1 the client requests the 1st KSK. The node redirects transparently to the CHK in the KSK redirect, and needs a _long_ time until he gives up and reports code=28 to the client. The client does not know if the request failed because the CHK does'nt exist at all, or if the CHK could not be retrieved this time, but later. The client steps over all 100 KSK keys (each one failing after a long search time) and after this the client have to request all keys again during next update, because some CHK might be retrievable now. On board_2 the client also requests the 1st KSK key. The node redirects to the CHK key, and after a _shorter_ time the request is successful or not. If it _is_ successful the client marks the slot used (tried never again) and inspects the retrieved data, which are random and therefore invalid. If the request was _not_ successful, the client gets code=28, but this time he knows that the redirect points to valid CHK key! So a retry will be successful later, and its worth to retry. So why does the node even allow to insert a redirect to not-existing data? He should check if the data is retrievable from the inserting node. I can't understand why someone should insert a redirect to content that cannot be retrieved by himself. I think an indication if the CHK is valid would be better than without. Even with patched nodes, each insert node on the htl chain could check if the CHK is known, and it is known if at least e.g. 2 nodes (on the chain or neighbors) say it is valid. I don't know if my points are valid, but I want some explanations that help me to understand this. A simple 'its not worth to think about', without to provide a working circumvention for this, its not enough for me. And why is there no type of key in 0.7 that is designed for applications like Frost that provide a global messaging feature? There are many improvements for freesites (e.g. USK) and easy filetransfer (although to less detailed for clients, currently). On 1/3/07, Dave Baker <dbkr at freenetproject.org> wrote: > > If a client could determine that the inserted KSK was inserted > > as redirect to a specific key, > > That's the problem though - I don't think that's possible. Even if it were > marked somehow on insertion, it would only require some minor hackery of the > node's source to make a user-created redirect look like a node-created > redirect. > > Again though, I'm still not convinced it's worth worrying about. > > > Dave > > On Wednesday 03 January 2007 17:05, bbackde at googlemail.com wrote: > > It would help to prevent the usage of specific keys that were inserted > > as a redirect target of a KSK. If a client could determine that the > > inserted KSK was inserted as redirect to a specific key, we could > > easily drop and ignore this KSK. We would only allow KSKs that were > > inserted as data. This prevents attackers from inserting alot of KSK > > redirects (which is very fast, compared to the insert of a KSK with > > the data) in a short time, and it prevents spreading of specific CHK > > keys over KSKs. > > So I see some advantages there. It should'nt not too hard IF the node > > knows when a KSK was inserted as redirect to a specific CHK. If not I > > think we will have some more problems with KSK attacks than under 0.5. > > On 0.5 this kind of attack is not possible such easily... > > > > On 1/3/07, Dave Baker <dbkr at freenetproject.org> wrote: > > > I don't really see as that's relevant, since it would be spoofable > > > anyway. Surely the point is setting a limit on the size of a key when > > > it's requested (frosy must do this, surely..?) and limiting the number of > > > redirects (which the ClientGet command doesn't seem to have an option > > > for, but I assume the node has a sensible limit and detects redirect > > > loops). > > > > > > This would prevent the second attack. I don't really see that the first > > > is a problem anyway, since the risk of downloading arbitrary content is > > > implicit when using frost. You could potentially only allow keys that are > > > non-redirect KSKs (thus limiting the size of a frost post to 1k, which > > > may or may not be desirable). That would prevent it, but as I say, I > > > don't really see it as a problem assuming that there's a filesize limit. > > > > > > > > > Dave > > > > > > On Wednesday 03 January 2007 14:19, bbackde at googlemail.com wrote: > > > > I think he means that a client should be able to determine if a > > > > KSK/SSK was inserted as a manual redirect to another key, or if the > > > > KSK/SSK was inserted with data and a redirect to the content was > > > > automatically created by the node. > > > > > > > > Is it possible to separate this in the node? This would be a great and > > > > simple solution. > > > > > > > > On 1/2/07, bo-le at web.de <bo-le at web.de> wrote: > > > > > hi, > > > > > > > > > > just in the frost-board 'frost' > > > > > ----- EvilDude ----- 2007.01.02 - 07:22:29GMT ----- > > > > > > > > > > If I wanted to download a key but it was rare, could I increase my > > > > > chances of getting it if I inserted a KSK redirecting to it, forcing > > > > > every frost user to download that file? > > > > > > > > > > Similarly, could I create a denial of service attack by inserting a > > > > > bunch of redirects to all the large files I can find? I'm not going > > > > > to attempt it this time around, I'm just wondering. > > > > > > > > > > ----- > > > > > > > > > > The fcp client should be able to detect the redirects if wanted. > > > > > > > > > > My suggestion: a new progress, that show the redirects. > > > > > > > > > > static final int showRedirects = 128; > > > > > > > > > > verbose=verbose | showRedirects > > > > > > > > > > > > > > > Now the ClientGet returns a new progress message > > > > > > > > > > FollowingRedirect > > > > > Identifier=hello > > > > > RequestedURI=freenet:KSK at something-1-2 > > > > > RedirectTargetURI=freenet:CHK at jdncdj,hdcbd,a8 > > > > > EndMessage > > > > > > > > > > Now the client app can decide how to handle it. > > > > > > > > > > thanks. > > > > > > > > > > -- > > > > > Mfg > > > > > saces > > > > > > > > _______________________________________________ > > > > Tech mailing list > > > > Tech at freenetproject.org > > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > > _______________________________________________ > > > Tech mailing list > > > Tech at freenetproject.org > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >
