-----BEGIN PGP SIGNED MESSAGE----- ( FreeNet Home Page: Archive: Message #214 ) ( Date: Jun 19 1999 21:41:03 EDT ) ( From: Adam Back ) ( Subject: Re: URL resolution vs publishing service (vs Re: content blind servers) ) > The descriptiveness of the freenet URL will depend upon the users > adopting consistent conventions for different types of data. > > There are existing proposals for extended URL types. > > http://www.ietf.org/html.charters/urn-charter.html > http://www.ietf.org/html.charters/urlreg-charter.html > > they basically view this as a specialization of a URL. You are > defining a new URL type, one for each type of data. eg. ISBN is > listed and other types would fit into the framework, such as say phone > no., musical work, etc. > > To my mind if you want to do this (have descriptive URLs), you may as > well make use of existing technology, and work within it's framework > to define new URL types for useful indexing types you feel aren't > covered. This makes a lot of sense to me. If we model these descriptive URLs as the freenet keys, prior to being hashed, then the match to Adam's eternity work is very close. The usual first part of a URL is a hostname which has all sorts of problems associated with it. What we really want to a location independent way to name data. File systems like AFS and DFS, which I have worked on for years, make great hay out of this extra level of flexibility. In AFS/DFS there is an explicit level of indirection between obtaining the name and locating the data: the client asks a location server which file server currently stores the data. In FreeNet this process is essentially served by a giant cache that retrieves data by key. To provide anonymity and more decentralization, in FreeNet and Adam's usenet Eternity (uE) there is no authority that controls the namespace. Anyone is free to assign any name to his data. This can provide anonymity if permission to store data into the system is uncontrolled. However, it really cannot achieve censor-proofness. Once an attacker finds the name (key, virtual URL) of a piece of data he wants to suppress he just inserts a replacement. The data's name is normally not secret (though it might be private within some small community), otherwise no one would be able to see the data. There are two other problems with the approach of attaching data to arbitrary keys: accidental name collisions and the fact that legitimate updates are unsynchronized. The former problem may be somewhat mitigated by the URL/URN standardization efforts that Adam mentions. The problem of synchronization, however, is a serious issue if this system is to be used as a "real" file system by everyday applications such as software development, mail delivery systems, and other collaborative efforts. These distributed applications can benefit greatly from being build on a distributed file system infrastructure. You might say: "leave the traditional applications to traditional file systems". But that misses the point that these mainstream applications will provide the both the haystack for hiding needles and the financial support to keep in running. Neither of these benefits, ultimately stemming from synchronization, is to be sneezed at. There are two fixes needed to solve these three problems. The first is to generate the keys from hashes of the data's contents: content hash based keys (chkeys). This way the only way (assuming SHA remains unbroken) that two files data will have the same key is if they have identical contents. This seems perfectly compatible with FreeNet except for the realization that keys really will be totally uncorrelated with each other or the data they match. This may have implications for the caching and data location algorithms used by FreeNet. The second part of the fix, much as you're all going to hate it, is to have real directories form the namespace. These directories need to be owned by public keys who control, and are responsible for, their entries by serving them out of real, not easy to hide, servers. The namespace allows people to find and refer to data, while the chkeys make the data censor-proof without subversion of the entire caching infrastructure, at least for popular (infamous) data. While the namespace does represent a point of attack, the name to key mapping is arbitrarily replicateable in the sense that anyone, anywhere can add a name to a part of the namespace under his control that points to some key of interest to them. We can avoid the centralization problem implicit in global names by taking an approach described by Carl Ellison[1]. Every participant defines his own namespace which forms the root of all pathnames he uses. By convention he can refer to several global well-known names that map to directories that form the roots of the bulk of the public namespace. In today's, DNS dominated world, these top-level directories would correspond to "com", "org", "net" and so forth. However, another node in a user's root would be for private stuff that he controls and doesn't want to have public. It will also be useful to include here shortcuts or aliases for frequently used names much like a browser's bookmark file. The main consequence of these privately rooted names is that they won't be globally resolvable. If I send someone else a script or an HTML file that refers to pathnames using my local aliases, the recipient probably won't be able interpret them because his private component of the namespace will be laid out differently than mine. Between the private and public parts of the namespace, users are free to establish names that are shared within a limited community. These directories would still be owned by someone (or some group that shares control of its public key) but only members of the community would know how to access it. Using a private root coupled with conventions on laying out the top-levels of the hierarchy allow global names without centralized control of the resulting namespace. Online servers for namespace directories allow rapid updates and synchronization of content between producers and consumers. However they have two basic problems. At the top of the hierarchy heavy loads will make impossible performance demands on servers. While anonymity requirements impose the impossible demand on a server that it be available yet untraceable. The solution to both problems is to realize that directories can take two forms, either a pointer to a server providing directory services plus a public key or a file whose (signed) content is the directory. In the latter case, the file is a directory snapshot which can be widely replicated and cached without imposing undue load on the directory's owner. Users then must take responsibility for obtaining periodic updates from reliable sources. At the top of the public namespace, these snapshots provide consistency (new releases of the top parts of the public name spaces could be signed by many trusted parties before being widely accepted by individual users) and scaling (immutable snapshots can be arbitrarily-widely cached and replicated). In the semi-private parts of the namespace, the keys of recently released snapshots of controversial content would make the rounds using informal contacts such as mailing list announcements or private email depending on whether anonymity or privacy is the primary concern. Though when real privacy is needed the snapshot can also be encrypted to set of public keys of the authorized users. Online directory servers can easily implement read permission by referring to an access control list. Ted Anderson [1] I was never really involved with the X.509 and PK infrastructure discussions and anything I know is way out of date. I may have misattributed this idea to Carl. The idea I am most familiar with (though I don't have a reference handy) was expounded by Carl Ellison's work on Simple Public Key Infrastructure (SPKI) and elaborated by Rivest and Lampson in a 4/26/1996 paper I do have called "SDSI - A Simple Distributed Security Infrastructure". -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN+eNTwGojC9e/wyBAQGOpgQAiHxMNXUdz4S2atNxhcnxsv7Pvp3xJlFP AZMrXYBO++jNDv2Hv1s3LyjaWzqGHzev/XjG0cts4wfbKd/u5Q8+j0fsvQC1oibF R3obRirKv41objG/8Bx+ziMK99cHxJXFPkoUOi6dRCIycetnSQWj7MzaN6S+dptf rCifH3VVfO8= =7VA/ -----END PGP SIGNATURE-----