On Fri, May 04, 2001 at 11:20:46AM +1200, David McNab wrote:
> Which is why I'm keen to take up Brandon's suggestion about multiple DNS
> registries, and empowering anyone to become a DNS registrar. I don't want to
> be held responsible for content on FreeWeb.
But then you lose the benefits of a unified namespace. I really think
that this additional layer is an ugly kludge, and creates far more
problems than it is worth. For me it ruins an otherwise excellent piece
of software, and my advice is to strip it out, and forget about it.
> But did you read in my earlier reply about the 'fwgetdns' utility, which
> *anyone* can run, and which bypasses me completely in loading DNS records
> into the user's own local DNS cache?
Again, that is spammable.
> Here again is where the multiple registries system will offer some remedies.
> If one key index is being spammed, it can be blacklisted in favour of
> cleaner registries.
But this still adds a whole new level of complexity to the process of
reaching sites in Freenet, and relying on multiple registries loses the
unified namespace which even the much-maligned KSKs benefit from.
> >It is also totally unnescessary, if people want friendly ways
> >to access their sites in Freenet, why not use KSKs - that is what they
> >are there for?
>
> The first pre-alpha used strictly KSKs, and had no 'registry' system - I got
> shot down by others for using inherently insecure key types.
> Milking inform.php and doing htl=1 inserts of a KSK all over the place can
> take down a site, or result in another site appearing in its place.
People have a choice, they can either pass around insecure but
user-readable KSKs, or pass around secure key-types such as SSKs or
CHKs.
> It's a bit of a brain rattler, how to come up with a translation path which
> can render a short human-readable string into a secure Freenet key:
> 1) With no hazard to anonymity
> 2) Without relying on out-of-band means such as mainstream websites
> 3) With no vulnerability in the security or accessibility of the translation
> path
If people want to render a human readable string into a secure Freenet
key then they should use KSKs, and accept the risk. If they don't want
to accept this risk, then they should pass around SSKs. Simple.
> SSKs are tight and secure keys, but can't be written to without the use of a
> private key. Revealing this private key makes them as insecure as KSKs.
I have no idea what you are getting at here. The whole point is that
SSKs can't be written to without the use of a private key. If you are
talking about some form of submission mechanism then KSKs are perfectly
well suited to that.
> If you, Ian, or anyone else can suggest something better, I'd love to hear
> it, and put it into the next FreeWeb release.
Easy. Stick with SSKs. They have been working fine to-date, are
secure, and don't break compatibility with existing freenet clients.
Your mechanism is a solution that doesn't really solve a problem, but
creates plenty.
Ian.
PGP signature
