On Wed, Dec 27, 2000 at 07:49:17PM -0600, Mark J. Roberts wrote:
> On Thu, 28 Dec 2000, Oskar Sandberg wrote:
>
> > But KSKs are inherently insecure and should be avoided when not absolutely
> > necessary. If you do have a "map" file like you suggested, then it should
> > never be located directly under a KSK but rather under a secure key type
> > (to which KSKs can be redirected). Since the map file would form the core
> > document of the site, it is absolutely imperative that it resides within a
> > secure key so that people can bookmark the site and be sure they are
> > returning to the same place.
>
> "Absolutely imperative" exaggerates the risk. The mapfile will most likely
> remain on the user's own node unchanged. If evil nodes start getting good
> at cracking popular KSKs then all KSKs should be banned and new nodes
> should start rejecting them, just like how we now refuse to store KSKs. If
> there are only a few isolated incidents, and no epidemic, we can merely
> strongly deprecate them. But for now, they are useful and will help to
> increase Freenet's popularity and usability.
(you meant KHKs the third time.)
The reason we stopped using KHKs all together was that ease with which
they could be cancered was a concern not only to the validity of the key,
but the health of the entire network. It was also because we had a better
method of doing the same thing. We will continue to use KSKs as long as
those reasons do not hold for them, but that does not mean that we should
have any faith in the validity of data coming from a KSK request.
When you request a KSK you get data from a person who wanted to insert
data under that keyword. That is all you can expect to get, and all we can
count on people getting. For many things and most people this will work
well enough as a namespace, but we cannot premit ourselves to get lazy
and assume that.
> > 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.
> > 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.
> 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.
>
>
> --
> Mark Roberts
> [EMAIL PROTECTED]
>
>
> _______________________________________________
> Freenet-dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
