On Wed, Jan 03, 2007 at 06:05:51PM +0100, 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...

"Inserted as data" ? Meaning what exactly, from a node's point of view?
Any data which does not fit in a 1kB KSK will be inserted as data and
redirected to.
> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/tech/attachments/20070115/80977509/attachment.pgp>

Reply via email to