[Freedombox-discuss] Distributed Naming BOF Questions

Fri Aug 5 19:52:48 UTC 2011

On Fri, Aug 05, 2011 at 01:54:56PM -0400, Isaac Wilder wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have been following the conversation on distributed naming for some
> time, and it still seems to me that we could drastically simplify the
> problem, for ourself and for all users of the box. Details follow.
> 
> On 08/05/2011 01:07 PM, Daniel Kahn Gillmor wrote:
> > On 08/04/2011 11:24 PM, John Walsh wrote:
> >
> >> If, the FBX does issue domain names it could reduce the attack
> >> surface by picking a single TLD
> >
> > hm. this would be either "reducing the attack surface" or
> > "maximizing the value of the target".
> >
> > That is, if all freedomboxes used DNS names hosted in some subzone
> > of example.org, then a malicious adversary would need to lean on
> > either:
> >
> > * the root zone operator * the .org zone operator, or * the
> > .example.org zone operator
> >
> > once they did this, they could control *every* freedombox. I'm
> > not convinced this is a win. :(
> This seems like a non-starter to me.

In theory it seems to me too, but as most of the ongoing discussion seems
to have stated, it will be hard to get rid of the problematic DNS
protocol, at least at the beginning, at least the time the network effect
takes place and people begin to move from it. For this network effect to
take place, it will probably require a lot of work on the outside of the
FBX project itself, so that others joins the "alternative" we might begin
to setup.

In the meantime we might have to deal with DNS. And in this area, the only
workaround I can see against the scenario dkg described, or at
least for it to be very hard to happen, is to rely on two things:

- having this top-domain that can delegate sub-domain zone being
  registered by very public and trusty entities/individuals, so that it's
  very hard to put pressure on them. Best way I can see would be to have a
  public association registered in a "privacy-friendly" country (maybe
  like iceland), and having as members multiple entities from several
  countries. Borders are also often a stopping wall for official procedure
  too after all.

- opening the sub-domain registration to non-FBX owners. One thing
  that can probably help to stop any attempt to shutdown the domain is
  having a big community using it, so that any attack against it can't
  happen without having a reaction from this big community, and a lot of
  noise about it because it concerns a lot of people. This often makes
  governments think twice about it before attempting something.

Writing this, I'm wondering if trying to use something like fbx.eu or
freedombox.eu domain could be interesting. Does anyone have heard of
stories about .eu domains being shut down?

Appart from such a workaround, I don't see a way not to be vulnerable to
the scenario described above if we use DNS.

> >
> >> Again if the FBX does issue domain names can't the foundation
> >> pick a host that uses DNSSEC effectively, or does every host have
> >> to use DNSSEC for it to be effective?
> >
> > For DNSSEC to be cryptographically effective,
> >
> > 0) every zone used needs to signed properly, and publish signing
> > keys for its subzones 1) every named host needs to have key
> > material published for that host (via e.g. DANE or sshfp records)
> > in DNS 2) every *client* needs to actually check every DNSSEC
> > signature and verify it properly (this means recursive verification
> > back to widely-published, pre-seeded root zone signing keys)
> >
> > IMHO, part (2) is the hard part. it's certainly the part that is
> > farthest from completion today.
> >
> > Note that even if this is all done, DNS is still vulnerable to the
> > points of centralized control i described above.
> >
> Why don't we simply obtain a block of v6 space, such that every box
> could have its own, static IP address. Using ManusVexo, or other
> discovery processes, we could slowly build up a *local* hosts file, on
> every box.
> 
> I admit that there needs to be some mechanism for lookup, but it seems
> to me that it should be completely separate from existing global DNS
> hierarchy.
> 
> If we adopted a static-addressing scheme, it would leave a couple of
> big lookup questions:
> First, given somebody's name how do you obtain their address? (Think
> of this as the 'friend request'. A one-time process to add someone to
> your address book). In the case of key exchange, this is easy, because
> you can just exchange your addresses as well, but what about when
> you're trying to find somebody that you knew long ago? This might be
> as simple as a distributed, open lookup table (with voluntary inclusion).
> 
> Second, If boxes are going to be used *en mesh*, they are going to
> have to announce their availability at the address of the mesh
> gateway. This seems more complicated to me. Having announcements
> propagate as quickly as possible seems core. Anybody have ideas in
> this regard? I could see co-opting DNS technology for our own
> application, but we would need our own infrastructure.
> 
> Seems like a perfect application for a DHT-based system.
> Does anybody know what I2P does for name resolution?
> >> IMHO, I don't think we can stop feeding our personal data and
> >> relationship information back into the existing system, because
> >> unfortunately, we will not be able to get *all* our family and
> >> friends on an FBX.
> Never say never. There is a lot at stake here, and though the scope of
> the vision is large, there is no reason why sovereign computing
> shouldn't become the norm. The advantages are many. Push and pull
> factors abound. If the UX is compelling and intuitive, there's no
> reason that we couldn't get everyone on the box.
> >
> > there are network effects at work here (if all *their* family and
> > friends are using this alternate infrastructure, they'll have
> > incentive to switch themselves), and this doesn't need to be an
> > all-or-nothing thing.
> Agreed that it doesn't need to be all or nothing. The web is going to
> be with us a long time, but the internet longer.
> >
> > But we do need to find ways we can help people cut down on the
> > amount of information they feed to the surveillance regime, or else
> > the project will end up being just pretty window-dressing, and
> > might actually increase surveillance and repression. That would be
> > a sad outcome.
> What I am working towards is the emergence of many autonomous systems
> (composed of mesh-networked FreedomBoxes) that are owned and operated
> cooperatively. We could start off with packet tunnels and dark leases,
> and move towards routes that we (humanity) owns.
> >
> > Regards,
> >
> > --dkg
> >
> 
> carefully, as always,
> 
> imw
> >
> >
> > _______________________________________________ Freedombox-discuss
> > mailing list Freedombox-discuss at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJOPC5wAAoJEA8fUKCD77NLCOoH/0QBO/CQ+tmPXl5Y2i1bNKeU
> wUad3DRQDQjwmVpGjFUwRnZeUy6ZY+KlMhMzepaXNlX1vIg20DEKcx5mR+r1o93s
> QVFJbewrIUVsdcXMjvpmX4cNXQDOZCXCNuGte1LuJN5eYZ5GWAC/sCSrVqBM/MUa
> ThQpe4WUuJsGI3QT2hvpl0C0KmvcXNfXAZtb1cldxcf54zlHTFq/dXz0lFMt9C1L
> MeRI0UUBDZUuYzGiJ6hU4Vz5gaqlFM61d40Dx9UGhh5a5nOURSSaOuMaxlbyo8Zt
> MspsrzE1UjGw6b+vM7oQ8i7mlRG7DZcrEAZvQ6RN4lZd8zBn88L7gm9eJNAjJSo=
> =pY4F
> -----END PGP SIGNATURE-----
> 

> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss