On Thu, 28 Dec 2000, Oskar Sandberg wrote:
> > > The clients will just have to be smarter (capable of carrying the
> > > mapping name over a redirect if necessary), and links must, like
> > > bookmarks, be to a secure key all the same.
> >
> > There is a much greater probability of recieving a subverted KSK the first
> > time, because after that it'll probably live on your node. If the KSK is
> > corrupt from the beginning there's nothing we can do.
>
> Requesting something by KSK the first time is like saying "I want
> something that somebody thought should be returned from the keyword
> 'pigdog'". Nothing more. The second time however, there is a very real
> necessity that what comes back is the same site that you had last time.
>
> And saying "it will probably live in your node" is not good enough. This
> has to work for everybody, including those who are not running there
> nodes, or who had to restart it, or just waited long enough before
> returning. This is what we have the secure keytypes for, and there is
> nothing stopping you from inserting the actual map data under a secure
> keytype.
I agree.
> > > Like so often with security, inexperienced users will be likely to slack
> > > on this if given the option, but in fact they DO want to be sure that what
> > > they are linking or returning to is actually what they left.
> >
> > And how do they know that what they just saw was legit? So they download a
> > subverted linux kernel the first time, don't notice, and keep on doing
> > it. It's safest to link through trusted, reliable, secure-key sites to any
> > new material. Even then, the site maintainers could be decieved into
> > posting subverted software, but at least you stand a better chance of
> > finding out about it before it's too late. (And, as you said, too late
> > comes too soon.)
>
> How to validate something the first time is obviously not a problem that
> can be solved in band. However, by putting all relevant data under secure
> keys you can be sure that a) you can safely return to a document where you
> had been before b) you can safely link to a document and be sure that
> people following the link will end up where you want them.
Embedded KSK links should be deprecated, if they aren't already. And
nothing (especially important data like mapfiles) should never be directly
under a KSK. I agree.
> > But really simple keys are essential for bootstrapping Freenet, IMHO. Once
> > we win a userbase, then we can concentrate on tightening up the
> > security. Without users it's all useless, so I vote for keeping our
> > priorities straight.
>
> This is essential. You can have simple keys, but it is extremely important
> that the essential data itself is under a secure key. And making sure of
> this will not complicate things for the user, it will only make the
> programming a little more difficult for us.
This is an issue on the insert side. Is anyone going to try to defeat
InsertClient and insert directly into a KSK? And if they do, what should
our response be when we request it? Complete rejection of the data or
merely a warning with an override?
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
