<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
I have been following the conversation on distributed naming for
some<br>
time, and it still seems to me that we could drastically simplify
the<br>
problem, for ourself and for all users of the box. Details follow.<br>
<br>
On 08/05/2011 01:07 PM, Daniel Kahn Gillmor wrote:<br>
<span style="white-space: pre;">> On 08/04/2011 11:24 PM, John
Walsh wrote:<br>
> <br>
>> If, the FBX does issue domain names it could reduce the
attack<br>
>> surface by picking a single TLD<br>
> <br>
> hm. this would be either "reducing the attack surface" or<br>
> "maximizing the value of the target".<br>
> <br>
> That is, if all freedomboxes used DNS names hosted in some
subzone<br>
> of example.org, then a malicious adversary would need to
lean on<br>
> either:<br>
> <br>
> * the root zone operator * the .org zone operator, or * the<br>
> .example.org zone operator<br>
> <br>
> once they did this, they could control *every* freedombox.
I'm<br>
> not convinced this is a win. :(</span><br>
This seems like a non-starter to me.<br>
<span style="white-space: pre;">> <br>
>> Again if the FBX does issue domain names can't the
foundation<br>
>> pick a host that uses DNSSEC effectively, or does every
host have<br>
>> to use DNSSEC for it to be effective?<br>
> <br>
> For DNSSEC to be cryptographically effective,<br>
> <br>
> 0) every zone used needs to signed properly, and publish
signing<br>
> keys for its subzones 1) every named host needs to have key<br>
> material published for that host (via e.g. DANE or sshfp
records)<br>
> in DNS 2) every *client* needs to actually check every
DNSSEC<br>
> signature and verify it properly (this means recursive
verification<br>
> back to widely-published, pre-seeded root zone signing
keys)<br>
> <br>
> IMHO, part (2) is the hard part. it's certainly the part
that is <br>
> farthest from completion today.<br>
> <br>
> Note that even if this is all done, DNS is still vulnerable
to the <br>
> points of centralized control i described above.<br>
> </span><br>
Why don't we simply obtain a block of v6 space, such that every
box<br>
could have its own, static IP address. Using ManusVexo, or other<br>
discovery processes, we could slowly build up a *local* hosts
file, on<br>
every box.<br>
<br>
I admit that there needs to be some mechanism for lookup, but it
seems<br>
to me that it should be completely separate from existing global
DNS<br>
hierarchy.<br>
<br>
If we adopted a static-addressing scheme, it would leave a couple
of<br>
big lookup questions:<br>
First, given somebody's name how do you obtain their address?
(Think<br>
of this as the 'friend request'. A one-time process to add someone
to<br>
your address book). In the case of key exchange, this is easy,
because<br>
you can just exchange your addresses as well, but what about when<br>
you're trying to find somebody that you knew long ago? This might
be<br>
as simple as a distributed, open lookup table (with voluntary
inclusion).<br>
<br>
Second, If boxes are going to be used *en mesh*, they are going to<br>
have to announce their availability at the address of the mesh<br>
gateway. This seems more complicated to me. Having announcements<br>
propagate as quickly as possible seems core. Anybody have ideas in<br>
this regard? I could see co-opting DNS technology for our own<br>
application, but we would need our own infrastructure.<br>
<br>
Seems like a perfect application for a DHT-based system.<br>
Does anybody know what I2P does for name resolution?<br>
<span style="white-space: pre;">>> IMHO, I don't think we
can stop feeding our personal data and<br>
>> relationship information back into the existing system,
because<br>
>> unfortunately, we will not be able to get *all* our
family and<br>
>> friends on an FBX.</span><br>
Never say never. There is a lot at stake here, and though the
scope of<br>
the vision is large, there is no reason why sovereign computing<br>
shouldn't become the norm. The advantages are many. Push and pull<br>
factors abound. If the UX is compelling and intuitive, there's no<br>
reason that we couldn't get everyone on the box.<br>
<span style="white-space: pre;">> <br>
> there are network effects at work here (if all *their*
family and <br>
> friends are using this alternate infrastructure, they'll
have<br>
> incentive to switch themselves), and this doesn't need to
be an<br>
> all-or-nothing thing.</span><br>
Agreed that it doesn't need to be all or nothing. The web is going
to<br>
be with us a long time, but the internet longer.<br>
<span style="white-space: pre;">> <br>
> But we do need to find ways we can help people cut down on
the<br>
> amount of information they feed to the surveillance regime,
or else<br>
> the project will end up being just pretty window-dressing,
and<br>
> might actually increase surveillance and repression. That
would be<br>
> a sad outcome.</span><br>
What I am working towards is the emergence of many autonomous
systems<br>
(composed of mesh-networked FreedomBoxes) that are owned and
operated<br>
cooperatively. We could start off with packet tunnels and dark
leases,<br>
and move towards routes that we (humanity) owns.<br>
<span style="white-space: pre;">> <br>
> Regards,<br>
> <br>
> --dkg<br>
> </span><br>
<br>
carefully, as always,<br>
<br>
imw<br>
<span style="white-space: pre;">> <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>
iQEcBAEBAgAGBQJOPC5wAAoJEA8fUKCD77NLCOoH/0QBO/CQ+tmPXl5Y2i1bNKeU<br>
wUad3DRQDQjwmVpGjFUwRnZeUy6ZY+KlMhMzepaXNlX1vIg20DEKcx5mR+r1o93s<br>
QVFJbewrIUVsdcXMjvpmX4cNXQDOZCXCNuGte1LuJN5eYZ5GWAC/sCSrVqBM/MUa<br>
ThQpe4WUuJsGI3QT2hvpl0C0KmvcXNfXAZtb1cldxcf54zlHTFq/dXz0lFMt9C1L<br>
MeRI0UUBDZUuYzGiJ6hU4Vz5gaqlFM61d40Dx9UGhh5a5nOURSSaOuMaxlbyo8Zt<br>
MspsrzE1UjGw6b+vM7oQ8i7mlRG7DZcrEAZvQ6RN4lZd8zBn88L7gm9eJNAjJSo=<br>
=pY4F<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>