A scratchpad for working out what some say is impossible: a distributed, secure, human-friendly Domain Name System. The current P2P Sockets system already has a distributed and human friendly domain name system, but it is not currently secure.

Below is an area to work out how to achieve a system that is distributed, secure, and human-friendly/usable. Feel free to comment and post your ideas.

One way to achieve this is by making it reasonably distributed, reasonably secure, and fully human-friendly. It is reasonably distributed by having coalitions of super-peers shouldering certain responsibilities, such as co-creating and co-holding private keys that are used in certain computations; we use primitives provided by threshold cryptography so that no peer has enough information to recreate the entire private key. All systems are breakable; it is just how high you set the bar. We make the system reasonably secure by setting this bar high-enough for the applications that will be built using it, such as applications for small and medium sized businesses and applications for creative and political expression.

Scratchpad (not guaranteed to make sense):

Possible Solution

Have a group of peers come together and work out a combined private key using threshold cryptography. These peers use this private key for cryptographic timestamping. They hold no record of what was stamped, except perhaps for a short time within a time-window to solve the issue of the same domain name being submitted at roughly the same time. They will happily stamp everything. This is a first-come, first-serve system (i.e. the first person to ask for a name gets it).

The timestamping group takes a domain name string, and returns the following bundle, called the Host Name Bundle: (Host Name, Time Stamp, a newly generated public key for this domain name called Host Name Public Key). It also returns a private key that is newly generated, called the Host Name Private Key. The requesting peer creates a peer group using this information; it has the Name of Host Name and the ad also includes the Host Name Public Key. The requesting peer then securely distributes the private key to any peer that has agreed to replicate the content for this host name (they join the peer group as well), and stores the Host Name Bundle in some distributed storage system.

A client peer then does a search for the host name they want; they get back two things: * a collection of Peer Group Advertisements with the Name field set to the hostname and a Host Name Public Key (all but one of these will be fake). * a collection of Host Name Bundles (all but one of these will be fake)

The client peer somehow gets the public key for the timestamping peer group. It first verifies that each of the Host Name Bundles really came from the timestamping peer group. It then simply finds the one with the earliest time stamp, and pulls out the Host Name Public Key from this. It can trust that this is the accurate Host Name Public Key. It then selects the Peer Group Advertisement with this public key, and attempts to join this peer group by challenging the peer group to give it a digital signature. It uses the Host Name Public Key to verify the digital signature. At this point it now nows that 1) it is dealing with the earli

Whew! This works, but its overly complicated and not elegant, but at least it works. How can we simplify the system? The threshold cryptography scheme is detailed in http://citeseer.nj.nec.com/boneh97efficient.html while I haven't chosen a timestamping scheme.

Issues: * how do we do revocation? What happens if the timestamping peer group gets compromised? How do we do refreshes. * network partitions can break the system or give the illusion that a name is available when it isn't * the first-come, first-serve system can be abused as a form of denial of service attack

Can we make threshold cryptography a peer group service so that it can be used in many contexts?

Another Possible Solution

Simply setup some centralized timestamping servers. Client peers would already come bundled with the public keys for these timestamping servers. A timestamping server takes a domain name request, or really an arbitrary string, and returns the following bundle: The time the bundle was processed and a newly generated public and private key. (to be continued)

Can we provide Timestamp services as part of the top SuperPeer^? services? The assumption woudl be that the top SuperPeer^? was a clustered set of servers. You obviously coudl cluster JXTA SuperPeer^? through the JavaGroups^? framework which is opensourced.

What other services should be in the top superpeer besides Time stamping?

-- Main.shareme - 14 Oct 2003