[Freedombox-discuss] DHTs and Names

[Nick Daly]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Gilmore <gnu at toad.com> writes:

>> Somebody, please confirm that the project will continue to use DNS? 
>
> First, given that FreedomBox will use already-deployed technologies in
> the short to medium term, there is no real alternative to DNS.  So,
> yes, the project will continue to use DNS.
>
> Second, there are half a dozen poorly conceived projects to "replace"
> or "augment" the DNS, to provide "censorship resistance" and other
> desirable characteristics.  Unfortunately, few of them are being
> designed by people with actual experience at running a globally
> distributed, locally cached, high performance, high availability
> massive database.  Few of them are designed to be any better than DNS
> at resisting determined attacks.  (Know how to make a Kademlia DHT
> secure against deliberate poisoning by censors?  I don't either.)  And
> most of them seem to assume that DNS will still be around to handle
> 99.999% of the queries, leaving their odd corner to in theory handle a
> tiny fraction of the queries.  So they're all likely to fail -- or to
> not scale up beyond a few thousand nodes, which is the same thing.
> We'll be using the DNS for the foreseeable future.

The best "solution" I've been able to come up with for the naming
problem (the question of, "once I trust that you're you, how do I
identify you, how do I pick you out of a crowd?") is to basically abuse
every protocol that allows messages to be stored and retrieved:

- - Publish what amounts to a PGP-signed ID card with all your contact
  data for every network or protocol.  Do this for every network you're
  named in.

Set up a little front-end that'll submit the information for each
protocol, modularize the supported protocols, and you're golden.

This method of, erm, triangling Zooko's line is nothing more than an
inelegant cheat: relying on consensus of multiple vulnerable protocols
to determine what a person's current contact information is (and
throwing out "human meaningful names").  It's death by a thousand cuts
(one per vulnerable protocol) instead of just one cut (using a single
centralized service).  It reduces all naming problems down to a
Byzantine Generals problem.  It implies a protocol-agnostic
web-of-trust.

Huge downsides:

- - You have to update your contact info in all protocols at the same
  time.

- - Different update rates and expire times per protocol make updating
  (and even knowing when to update) difficult.

- - Change one piece of contact info, have to update contact info in all
  your protocols, which might cause other protocols to change contact
  info (in protocols that disallow editing messages).

- - Expired protocols can't be used for verification or contact.  You
  should've updated your contact info sooner.

- - It's the stalker's best friend.

- - It supports only static updates, unless every protocol supports really
  fast updating...  Otherwise, you're automatically out of sync when
  mixing static (slow) and dynamic (fast) protocols.

Importantly, other questions remain unanswered:

- - How do I get messages to you? (Routing/Transmission)

- - How do I know you're the person replying? (Verification)

- - How do we meet across non-intersecting Webs-of-Trust in the first
  place?  (How do we introduce new members to the WOT?) (Introduction)

- - There's probably an "authentication" question in there somewhere, too,
  but it might just be a synonym of "verification."

As I said, this solution sucks, because it relies on vulnerable systems,
but it is extensible enough to support any future protocols.

Maybe we could use PGP to sign and encrypt every message sent over every
protocol between FBXs, that would at least (naively) resolve the
authentication question.  Do new protocols always spring up fully
formed because it's impossible to implement naming, routing,
introduction, and verification on top of a running system independently?
I doubt it, but it must be easier that way.

Nick
- -- 
GPG: 0x4C682009 | 084E D805 31D8 5391 1D27  0DE1 9780 FD4D 4C68 2009
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk5VoXoACgkQl4D9TUxoIAkDSACfV0fBHd1RT4SxzDZeHXM1Ez5Q
Kt4An1YYWorWvm6oIRnG+/j06+bu8ROj
=S+qA
-----END PGP SIGNATURE-----