<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Sam,<br>
<br>
There are definitely problems with using a global DHT for name<br>
resolution - that doesn't mean they're insurmountable problems.<br>
<br>
I think the first thing we may have to do is step back, and
realize<br>
that in fact, the names need to be global in scope, but they don't<br>
need to be globally *unique*. Think of it as building a phonebook
for<br>
freedomboxes. Some people really *do* have the same name. What we
need<br>
is collision handling, not guaranteed uniqueness, in my opinion.<br>
<br>
So, you look up somebody's name in the FreedomTable (at this
point,<br>
I'm just having fun with it). There are 45 Eben Moglens. There are<br>
many possible solutions at this point, so let's take a look at
what<br>
we're really trying to accomplish. We need to turn the *right*
Eben<br>
Moglen into a routable IP address. The likelihood is that Eben (or<br>
whoever) is assigned an address dynamically by their ISP, and the
box<br>
is hidden behind NAT, to boot.<br>
<br>
So, instead of a simple (unique) name -> address pairing,
you've got<br>
to have something more like name -> catchphrase -> public
key -><br>
(current) v4 + v6 addresses. When a box moves from subnet to
subnet,<br>
it updates the final entry in that chain. I'm not quite sure of
the<br>
details on a multi-stage hash like that, but I see no reason why
it<br>
wouldn't work. Then, once you've got the identity worked out, you<br>
store the public key of the *right* Eben Moglen locally, along
with<br>
their address.<br>
<br>
You use that address until it doesn't work any more, and then you
do a<br>
new lookup based just on the key.<br>
It does seem that we would want to have some sort of access
control -<br>
that is, changing or making an entry for a given public key should<br>
probably require one to be holding the associated private key.<br>
<br>
It obviously requires the bootstrapping of some infrastructure -
the<br>
table probably should not be held by the entire fbx network. From
the<br>
standpoint of the FNF, this would be a sensible role for<br>
FreedomTowers, but the nomenclature is unimportant. The point here
is<br>
that the name table should be hosted by a collection of trusted
nodes.<br>
<br>
Have I missed something, or does this seem doable to folks?<br>
<br>
<br>
<br>
take care,<br>
Isaac Wilder<br>
The Free Network Foundation<br>
<a class="moz-txt-link-abbreviated" href="http://www.thefnf.org">www.thefnf.org</a><br>
<br>
<br>
<br>
I've copied Brandon Wiley of the Foundation for Decentralization<br>
Research on this, in the hopes that he may be able to demystify
some<br>
of the finer points of DHT usage. I've never spoken with Brandon,
but<br>
he's put out some really good material on DHTs.<br>
<br>
On 08/19/2011 05:34 AM, Sam Hartman wrote:<br>
<span style="white-space: pre;">> <br>
> Hi. I'd like to understand how these human readable names
that <br>
> we're going to insert into a DHT are going to work from a
security <br>
> standpoint.<br>
> <br>
> What stops me from taking your name? What stops me from
taking <br>
> names similar to yours?<br>
> <br>
> I'm skeptical of the advisability of globally scoped <br>
> non-hierarchically registered human readable names and
would like <br>
> to understand the service model and goals for this
proposal.<br>
> <br>
> _______________________________________________
Freedombox-discuss <br>
> mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a> <br>
>
<a class="moz-txt-link-freetext" href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a></span><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
<br>
iQEcBAEBAgAGBQJOTkFjAAoJEA8fUKCD77NLX3MH/1OqvmHMxTIRetg+gh9GX4aT<br>
Lu34nyn+c2RWFPiJIdDH5jO+GKYlTYCXWdUDG9y7qnOSxA5DaxPGEBdfrpdqtd7b<br>
WMnqZODyQxk358RTvkFHEid+SNRbQZRfnhIUAXDeYPueTnpD4SFCChHqO6NZ7krs<br>
YHDTd2o2qwFZp6HaVk+0ysAHHxZkKEhfFwHSejV015D5LRyUiTeWqs/DtghgYl/l<br>
8LBbT+MBGkHqiKie1dfWRwDw+oSRVQ/wg4gD3FW72+xNb3zeyOYDdwuOqw7BbAjo<br>
uEO5aZNgRZJZzYKNY5DIJjgPrS8hD64vnH77dJmuwoWv63mDkT1RSDXVZqfarPg=<br>
=QXTR<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>