[Freedombox-discuss] http://politics.slashdot.org/story/11/07/18/0153204/Security-Consultants-Wa rn-About-PROTECT-IP-Act

[bertagaz at ptitcanardnoir.org]

On Wed, Jul 20, 2011 at 08:46:38AM -0400, James Vasile wrote:
> On Tue, 19 Jul 2011 20:51:50 +0200, bertagaz at ptitcanardnoir.org wrote:
> > On Mon, Jul 18, 2011 at 04:14:37PM -0400, Ted Smith wrote:
> > > On Mon, 2011-07-18 at 12:19 +0100, Luke Kenneth Casson Leighton wrote:
> > > > a non-centralised non-attackable truly peer-to-peer
> > > > replacement for the existing DNS infrastructure. 
> > > 
> > > Is this something the FreedomBox Debian project or the FreedomBox
> > > Foundation have committed to producing?
> > > 
> > > Such a replacement would be an extremely sophisticated product of the
> > > conjunction of multiple technological advancements that simply don't
> > > exist yet. It was my understanding that the Freedombox project was more
> > > about integrating existing systems than attempting to develop novel
> > > solutions.
> > 
> > Having spent some time thinking about it, I agree this is actually not
> > really realistic to assume the that freedombox project would implement
> > such a system soon. 
> > 
> > At least for the use case in which owners would buy a domain and host it
> > on their freedombox. I don't see actually any way to be sure that this
> > domain couldn't be taken down.
> > 
> > Still I believe that the freedombox project could at least setup a dynamic
> > DNS service ala dyndns, where owners could register a subdomain.
> 
> Ian and I have spent a lot of time discussing how dynamic DNS might be
> useful.  We used to talk about just as you have a personal and a work
> email address, you might have a personal and a work URL.
> (e.g. responsiblecoworker.box.jamesvasile.com
> vs. crazypartydood.box.jamesvasile.com).  I have some doubts about that
> approach, but I still think dynamic DNS might ease some hard problems
> even though it introduces some difficult problems of its own.

Sure, one point that has been raised again and again on this list is to
know how different boxes might be able to find each other. And to keep
inter-operability with the current internet. For this, it will be hard to
get rid of the DNS problem.

> The Foundation has not so far considered as part of its mission the
> hosting of services to support deployed FreedomBoxes.  People keep
> asking us to do it, though, so maybe we'll consider such things in the
> future.  For now, though, I don't think we have the organizational
> bandwidth to take that on even as we do everything else.

DNS is the only service I think would be very usefull to be maintained by
the project, for the reason I described (community support and all).
Otherwise it would be too easy to shutdown one's domain, as usual it would
only hit a lone person.

> That said, if you want to spearhead the creation and maintainence of a
> freedom-respecting dynamic DNS service, we might be able to give you
> some organizational resources to do it.

I might maybe be able to host such a service. The only downside is that
I'm a lone and quite unknown guy, and that would put a lot of pressure on
me. Having an entity supported by the community, who's members would be
well known public persons would be the only way I can see to avoid having
the domain being taken down.

DNS isn't that much requiring a lot of resources that said.

> > 
> > I believe that the only way to actually workaround the super-hierarchical
> > DNS problem is by community support. If the top domain providing this
> > service was run by public well-known and supported
> > organisations/individuals, it would be hard to force them to shut down a
> > subdomain, or/and threaten them to do so, cause they are public entities,
> > with a big community supporting them.
> 
> One ideal for the FreedomBox is that it be self hosting.  All the
> servers it relies on should be other FreedomBoxes.  That's a lofty goal,
> though, and it would take a *lot* of time to make that reality.  For
> example, there is, AFAIK, no package to easily serve distributed dynamic
> DNS.  The upshot of all this is that any solution we choose here is
> likely to be less than ideal.  Again, though, if you see a solution
> here, I encourage you to work toward implementing it.

The necessary software already exists. I agree this must be self-hosted.
If such a service would exist, the only data that the service would have
to record is the subdomain zone delegation to the owner DNS service
running on her freedombox. She then would be responsible for this domain
data. 

That way there would be only two ways to shutdown a subdomain :
blacklist/seize the freedombox serving the zone record, but people could
share their DNS server and the zone should have multiple DNS serving it
(i.e friends's DNS server would agree to be slave for this subdomain). The
other way would be to attack to top-domain, that's why it has to be ran by
organisations/indivuduals like the one I described, making this attack
hard to play because of the community support.

This is the only way I see to quite quickly have the freedombox project
supporting the DNS service, in a realiable way and without letting FB
owners on their own.

> > 
> > Maybe the first todo in this direction would be to setup an organisation
> > (or use the freedomboxfoundation.org?), who's members would be well known
> > "privacy concerned" people/organisations, that would register a domain.
> > Then think about a way to do this service in a privacy aware way.
> 
> Dynamic DNS run by a freedom loving group sounds great. I'd use it.  It
> also sounds like a whole separate project in addition to the FreedomBox.
> I'm not going to tackle that any time soon, but I'd certainly cooperate
> with anybody who does.

But then, how would the freedombox interconnect to each others? How would
they be reachable for people outside of the freedombox network? Should
avery onwer register by herself a domain, and then be quite alone and
vulnerable to shutdown/blacklist?

This project can't just rely on the Tor hidden service onion names, not
everyone will want to have this only solution.

bert.