[Freedombox-discuss] DNS solution that doesn't require paying money or using a central server.

Tue Jul 5 04:12:38 UTC 2011

couldn't the originating user register through a distributed table, or
automatic registration if the website doesnt already exist, and this would
give this user the power to set up the default hosting locations
(freedombox, box's, some server somewhere, etc) This power user could
specify that if the default location (Location1) goes down, to then use my
specified location 2 (Location2)? This would allow a distrubuted approach
with some resistance to poisoning. The multiple locations of the mirrored
site backups could all be hosted on freedombox's for all we care, heck other
freedomebox users could opt to help host/mirror a site/file/ect

if a location that is mirroring a site goes bad, the admin could of course
remove this from the registered DSN setup

the real trick is, to keep these records, and connections anonymous. No
standard emails used for registration, not recording various information
like ip address's/macs

On Mon, Jul 4, 2011 at 11:58 AM, Marc Loupias <list at marc-loupias.fr> wrote:

> Hello,
> some comments on this :
>
>
>
>> First, WHAT PROBLEMS WOULD THIS SOLVE?
>>
>>
>>
>> 5) Eliminates the need for certificate authorities. (A FAILED SECURITY
>> MODEL, YES?)
>>
>>
>>
>
> GPG does not eliminate certificate autorities problems. It just move the
> trusting problem.
> The technology is not the problem, as you are using GPG or X.509 PKI the
> problem remains the same : Which self-signed certificate can i trust.
>
> This question can't be solved by any geeky technical hack, it is a matter
> of person.
>
> For exemple if the Mozilla Corpo dont trust VeriSign, it can build his own
> X.509 PKI and distribute his own root certificate in his browser. And the
> millions of people using it will see the Mozilla certificate as legal.
>
>
>   [...]
>>
>>
>>
>> WHAT IF I DON'T ALREADY HAVE THE CONTRACT? HOW DOES THE PLUGIN FIND IT?
>>
>>
>> SHORT FORM:
>> In most cases it already has the ID (in the URL), so it just downloads
>> the contract based on that ID, via P2P or from a Distributed Hash Table.
>> Then it verifies the contract based on the ID and the signature, and
>> then it actually connects to the website and displays it, using one of
>> the addresses inside the contract (whether via i2p, tor, freenet, ip,
>> dns, etc. The contract supports as many as you wish.)
>>
>>
>>
>>
>
> There is a big problem here.
>
> If i modify my contract, i need to update ALL the links on the web not only
> thoses on my website. Including those given by other people and pointing to
> my website.
>
> You write that the ID is the contract hash. So if i add a connection type
> or if i update the IP (moving to another ISP for example) the ID will
> change.
>
> It will quickly go to a maze of deadlinks.
>
>
>  [...]
>>
>>
>>
>> WHAT IF IT NEEDS TO RESOLVE THE NAME FIRST, TO GET THAT ID?
>>
>>
>> LONG FORM:
>> In this example we actually have to resolve the name "freedombox.otc"
>> and find the right contract.
>>
>> 1) The plugin can make a request via P2P. (Coming soon to
>> Open-Transactions out of necessity for the digital cash, due to the
>> nature of the minting files.) The plugin thus asks my peers to lookup
>> the contract ID in their own local lists, and so I can find the contract
>> via a "web of trust".
>>
>> 2) Optionally, alternately, or additionally, my plugin may contact
>> certain specialized "search engines for contracts", which I predict will
>> arise on darknets. This is only a matter of time.
>> Thus, instead of searching Google for "freedombox" and getting a list of
>> sites, there would be various darknet-based aggregator sites where I
>> could type "freedombox" and get a list of contracts.
>>
>> 3) Whether the plugin uses p2p or search engine, or both, EITHER WAY,
>> MULTIPLE CONTRACTS might come up for the SAME NAME!
>>
>> This is okay!!!!!! People automatically assume this is some big problem
>> to be solved, but you can instead realize that IT'S NOT A PROBLEM AT
>> ALL. The sun will still come up in the morning. The sky is not falling.
>>
>> 4) If such a name conflict happens, that's okay: just check the
>> fingerprint and approve the correct one. You'll see the list of IDs, and
>> you can click and view each contract. You probably got the site ID off
>> of a business card, anyway. THIS IS JUST LIKE VERIFYING A FINGERPRINT
>> FROM A BUSINESS CARD, OR VERIFYING A FINGERPRINT DURING OTR CHAT. (And
>> you only do it once, in the rare event of a conflict.)
>>
>>
>
> Oh no this is not okay.
>
> 99% of people need SIMPLE things.
>
> Giving them a choice before accessing a ressource on the net is bad for the
> user experience.
> In the most case, people will pick a random contract just because they dont
> understand what is goin on with this new window.
>
> And if they have a single click to access a ressource with DNS and 3 or 4
> with your system the result is known by advance : They will not use your
> system.
>
> There is a second big issue, i click on a link and my browser pop a windows
> with 10 contract pointing on freedombox.org. How can i choose the correct
> contract ? On which basis ?
>
> And what about softwares using your system ? For example P2P. Who will
> click on the right contract ?
>
>
>
>  5) In most cases, THIS STEP ISN'T NECESSARY, since in most cases you
>> will be clicking on a link, not typing the name by hand, and the link
>> itself will ALREADY have the ID, (no need to resolve it from the name.)
>>
>>
>
> I totally disagree, if someone wants to poison a domain, it just have to
> build multiple contracts on the same DNS and it will go in a total mess.
>
>
>
>  Instead, the plugin IMMEDIATELY loads (or downloads) the appropriate
>> contract based on its ID, then verifies its signature, and then connects
>> to the website.
>>
>> 6) Also, remember once you enter the ID the FIRST TIME, then the name
>> will work EVERY time after that. (Since the plugin can just look it up
>> locally.)
>>
>> 7) You can even choose to import contracts that both claim the same
>> name. (This will rarely or never happen.) When the plugin encounters
>> such an ambiguity, it'll just pop up the list and ask you to choose one.
>> No big deal!
>>
>>
>
> Choosing IS a big deal for 99% of the users. Especialyy on a trivial thing
> like clicking on a weblink.
>
>
>  8) The contracts themselves can be globally available in a DISTRIBUTED
>> HASH TABLE. This way the owner can continually update the contract,
>> everyone can see it, and it's censorship-resistant.
>>   9) It's easy to update contracts in the DHT as necessary. Perhaps the
>> "main ID" is just a DHT address where the "current version ID" can be
>> found. This way you can change versions without changing your main ID.
>> The DHT address can be a hashed public key, where the owner is the
>> holder of the private key.
>>
>>
>
> So the ID is not the contract hash ?
>
>
>
>> WHAT PROBLEMS DOES THIS SOLVE?
>>
>> 1) People can use any "DNS name" they want for their website. It will
>> never be "already taken".
>>
>> 2) There is no central "DNS server". No central authority.
>>
>> 3) Name conflicts are rare, and easily handled. Conflicts also naturally
>> cause the user to choose the right one based on the FINGERPRINT. Isn't
>> this a good direction?
>>
>>
> In your system, making a lot of contracts for the same domain name is a
> good way to down the entire system for a given DNS or any other connection
> type.
> And it introduce complexity where there isn't for the DNS. So people will
> just not use your system.
>
>
>  4) Supports ALL PROTOCOLS. (Whichever addresses you put in your
>> contracts... tor, i2p, ip, dns, freenet, etc.)
>>
>> 5) Eliminates the need for certificate authorities. (A FAILED SECURITY
>> MODEL, YES?) You already have the site's public key from their contract,
>> so your browser can just use that to encrypt a session key.
>>
>>
> It doesnt eliminate certificate authorities, it move the problem in a
> constellation of little certificate auth -> the people you trust, and the
> people trusted by the people you trust, etc ...
>
>
>
>
> Theses are my comments/questions. Maybe i am totally wrong but i'm curious
> about this.
>
>
> Marc.
>
>
>
> ______________________________**_________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.**alioth.debian.org<Freedombox-discuss at lists.alioth.debian.org>
> http://lists.alioth.debian.**org/cgi-bin/mailman/listinfo/**
> freedombox-discuss<http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss>
>

-- 
Thank you for your time
~Nathan
nathan1465 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110705/579eb145/attachment.html>