Difference between revisions of "OT Replaces DNS"
(Created page with "In the future, if the time comes that Open-Transactions becomes available in Firefox, in Chrome, etc, then it will be possible to use it as a replacement for the DNS system, w...")
Latest revision as of 16:57, 12 June 2013
In the future, if the time comes that Open-Transactions becomes available in Firefox, in Chrome, etc, then it will be possible to use it as a replacement for the DNS system, without having to have some central DNS registry. The rub being, you have to allow for name conflicts on the network.
Clearly there are always trade-offs in life, but I found this to be an interesting thought experiment. The obvious question is, "Why would you eliminate DNS, just to end up stuck without any name resolution?"
Ah-ha! But I didn't say there wouldn't be any name resolution! I just said we had to allow for potential conflicts. But it's possible that such conflicts are not really a problem, and it's just in our heads, and that's worth exploring. After all, I2P has a globally secure, unique namespace, as does Freenet.
Sure, those I2P "names" are, underneath it all, gibberish numbers (AS ARE IP ADDRESSES ALSO.) But people still somehow use names on I2P, don't they? They still refer to things by names, in person and in their eepsite URLs. How can this be when the only globally-unique namespace in i2p consists of gibberish numbers?
Could it be that our need for DNS just a false dream?
First, let's consider, what problems would this solve:
- People could use whatever "DNS name" they want for their website. It will never be "already taken". Obviously if you are violating trademarks or committing unfair business practices in the marketplace, yadda yadda then you are still subject to being dragged into court by McDonalds (or whoever), at least if you are in any way known and could be served.
- DNS servers could be entirely eliminated. In this picture, they're replaced by a combination of Ricardian contracts (which are self-verifiable), and a distributed hash table (I nominate Namecoin), which is censorship-resistant, along with some hash verifications between p2p clients.
- Ricardian contracts can eliminate CAs, aka certificate authorities. (A failed security model, yes? Does anyone seriously see CAs as anything more than a scam and hive of international espionage?)
- Name conflicts while real, will be rare, harmless, and easily handled. They are "part of the system" and no big deal. (As they are already in I2P.) Meaning, 50 years from now, it could be considered entirely normal if there are hundreds of fake "cia.gov" contracts floating around, or whatever other website. Every schoolboy would nevertheless know which one was actually the C.I.A.'s real website, and easily verifiable links to the correct one would exist all over the Internet. Or consider the retailers. If there were a few dozen fake "target.com" websites that posed any threat to Target, trust me, the first few characters in Target's hashed key ID would quickly be turned into a catchy jingle, printed on receipts, printed on the side of their shopping bags, rotated endlessly on television commercials, etc. They'd put it on billboards next to their MySpace and Facebook links. It'd be like the same thing. Who can forge such a fingerprint?
- Ricardian Contracts are able to unify the various protocols, since you can put as many different addresses as you want into your signed contract, including your .onion, your eepsite, your IP address, your "last well-known" DNS, Your Freenet public key, etc. These can all just be contract tags.
- No more domain squatting. No more monopoly control over specific names. No more having to PAY for any name! No yearly registration fees, no ICANN fees.
- Yet, paradoxically, you can still build up value in a specific name, and you can still sell that name and website later.
Here is how it would work, for example:
-- Let's say I type a URL into my web-browser, such as this: ottp://freedombox.otc/
-- The OT plugin would intercept this (due to the "ottp" or the "otc") and would then try to lookup the "freedombox.otc" domain from a local signed list.
-- It finds it in the list! (In this example so far...) The name resolves to a base62-encoded hash value from that list, so it now looks more like this: ottp://lkjsdf908q345kj.otc/
-- That hash value is the actually the ID for a Ricardian contract. (And the ID is a hash of the contract itself.)
-- The plugin loads up the contract using the ID as the filename (or local db key.)
-- The contract is self-verifying. How? Because if you hash the contract yourself, you should get the same ID that you started with. (An attacker can't change the contract without also changing the ID.)
-- Additionally, the public key for the signer of the contract appears IN the contract itself...
-- ...And the contract is SIGNED with that key. So you can verify the signature as well. (The plugin does all this automatically when it loads up the contract.)
THERE MIGHT BE A DOZEN DIFFERENT TRANSPORT PROTOCOLS IN THE CONTRACT...
-- Once the plugin loads up the contract, there are multiple ways to actually connect to the signer's website. Let me show you what I mean. Notice in the sample contract below, there is an IP address, a DNS, an i2p, a Tor address, and a Freesite.
-----BEGIN SIGNED CONTRACT----- Hash: SAMY <?xml version="1.0"?> <DomainNameContract version="1.0"> <entity shortname="freedombox.otc" longname="The Freedombox Website" email="[email protected]"/> <issue company="The Freedombox Foundation" email="[email protected]"/> <!-- CONNECTION TYPES --> <connection type="dns" address="freedombox.org" /> <connection type="ip" address="189.432.12.56" /> <connection type="i2p" address="jsdf98345hj.i2p" /> <connection type="tor" address="8546jkhds9f8.onion" /> <connection type="freenet" address="[email protected],c63EzO7uBEN0piUbHPkMcJYW7i7cOvG42CM3YDduXDs,AQABAAE" /> <!-- KEYS --> <key name="owner"> - -----BEGIN CERTIFICATE----- MIICZjCCAc+gAwIBAgIJAJWeuXi8XjVjMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNV BAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEQMA4GA1UEBxMHRmFpcmZheDERMA8G A1UEChMIWm9yay5vcmcxEDAOBgNVBAMTB1Jvb3QgQ0EwHhcNMTAwNzIyMjAxMTIx WhcNMTAwODIxMjAxMTIxWjBeMQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2lu aWExEDAOBgNVBAcTB0ZhaXJmYXgxETAPBgNVBAoTCFpvcmsub3JnMRcwFQYDVQQD Ew5zaGVsbC56b3JrLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtiu6 jU/R2Zm3AAo1jA4z/IVHyAnIFzp4kUNkLjEQ6bKG31PRaTcZTLPBkXsnQIFPx1Ky u9q8T9gjiKPAEurtPyoDdT99aWP1NREcg4/RJ2naWOEAXGh21PP22x31bvy6lOrv KqOSBfNTL43PEj0dKMIl0MNywzsVZGDqKXTStG0CAwEAAaMzMDEwCQYDVR0TBAIw ADAkBgNVHREEHTAbgg5zaGVsbC56b3JrLm9yZ4IJbG9jYWxob3N0MA0GCSqGSIb3 DQEBBQUAA4GBAEhRt14Ys7jhUg0mDKMMgZLLs8cbDNFqwoJynLVNgJUdlvwo/nzZ Mk0wWVw8ucaDdpSBufUx4G3h6KkTTKOAbkvncRGdCiqywvOjKIbUczWMDdJ9uE5m 5zGVZZ8C7EqaIIrv0OpW8WSryOCXvCFhLfKuZteELGmCCX2tQE9TqIsr - -----END CERTIFICATE----- </key> <key name="certification"> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com mQGiBDn6yYURBADM3qphMoDpvpp3Lk2KW0bpA+i1ne6Hwm24lW9w1dIJrw8CEc+S vAEhoGOAJNTO209NFYxcM+sA8XHp5aJpFHSbI536sfzbSVe3/MwdJ8JZXtbzcbHv ToBs1wScGTet2SGL6I9S3p7XUfprCYezBPRMCPOTxqR8pptotYOGXZoPZQCg/y0q CZjPJclqDY8Hf0X+DWnOMAkEAI4GnOpSq838/oElDAuZcLOvpTqTZ922pG1EJQmj Vh4P6br3ocrWnJSonkqFPLjihsVwGumO/hkyptrgqRV/vR9BmK1LKz901VaXbXPZ Lcns+XAg5sXxZcz87Dl4AduTF59ahHkc2bR7HqrvzRkXoQ/Q4ViLOifFISXXPKx8 3OazA/9Ip4W+gr8e/oub7MQFJZcyOfcN1KDFIjnObVIabpIlKPcTeEHGvd/WUHOJ PQQr1+WGZY1W9UjLo171ssL2/x2bXaqJ4Ukgf4aQpRb5lUqekCKgine6eUA1XjTw J+a/J3xP54/iEuqdDZYGuX5j0/EJCqbY7gggPNkDNH82XdfQ+7QzUmFjaGVsIFdp bGxtZXIgW2NlcnRpZmljYXRpb25dIDxyYWNoZWxAd2lsbG1lci5vcmc+iE4EEBEC AA4FAjn6yYUECwMCAQIZAQAKCRC30ABpXpgYMFTFAJ0WqZwUXbD0H7YCGR7rI8jB Rh8E2wCePBrQBC1+shZrXCY0proYCkYfWdA= =UObU - -----END PGP PUBLIC KEY BLOCK----- </key> <key name="serverCertification"> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com mQGiBDmhGRERBAC9F7VF7ZNcwhffdFS2Sg0AcsF9gdhEEggZmBT1ezM5BYEO4lvN EJjezFilNxMLE3mP9E95mtRUEEtIx4ViyAGjVPwRBVQA2BNf+rbvCReBhhlJTFkN GOSHd65k4mDCflJAn7EX2OpST9tEAhpBs82w4OxlHIxmnav8iyD0O07sHwCgzYJI Xv3TEqERh0eDPEQ80MqGYEkD/Aj12tRhZYhYlVtEmJ4MrET9Ezuyhn8kQv89iBNK u2mN//LK4cqfJos1SJ3qXT16AHQQvfI0AUsI1ZQ+piq9pZ+sUMwpRnoQHM5SKux5 UYcIM9aklW0zYAt+WjyrQBhN0eW0uzF40NVZHIH592dz/1RbNKf0hSDKBeCERTxk /zRDA/9rgvwyclIq4VTgA9AgwHC+JrKwbtJsawb4eYZPSbDe/pl2bQT9haTuLBKs Olz57Er5Vto6DWb1hs8gzb107u7CGYholr/tyjiPRhDvOcVQpZudkCE/1UXpawT/ P4tPUvrBIVNK5SmHVRz6nsJxMxYm6Pr14+t8mgS1jrr/TxFTW7Q+U3lzdGVtaWNz IE9wZW5QR1AgU09YIFtvcGVyYXRvcl0gKGRzczEpIDxzZXJ2ZXJAc3lzdGVtaWNz LmNvbT6IVgQTEQIAFgUCOaEZEQQLCgQDAxUDAgMWAgECF4AACgkQKfOLUygtdArw 3QCeJ8bEfVFS2etPkFus6esJfZ0+2OUAoK4AIIjFB+9CsoEkCn4dJBRTUKen =L806 - -----END PGP PUBLIC KEY BLOCK----- </key> </digitalAssetContract> -----BEGIN SIGNATURE----- fm7l4FyMW7p0ayZcBwq2JHGnSzRIwS75tvkNxpEnrvcahwv68RKFmxDr7Hz8000u d9oOznZpjga17gwSlTS1AsiX3GAix5CLCZLenAV6dUUsgEBOK2kCnB/6gc8c5FVP QH0mF0ICfxDPSY2Y0/lXVww8URis0mmHz3F+NX9S9B4= -----END SIGNATURE-----
Notice also that the keys are in the contract, so there's no need for any "certificate authorities" anymore. They are all spy agencies anyway.
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.)
WHAT IF IT NEEDS TO RESOLVE THE NAME FIRST, TO GET THAT ID?
(That has to happen once, after which it is cached locally.)
LONG FORM: In this example we actually have to resolve the name "freedombox.otc" and find the right contract.
- 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".
- 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.
- 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.
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.)
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.)
Instead, the plugin IMMEDIATELY loads (or downloads) the appropriate contract based on its ID, then verifies its signature, and then connects to the website.
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.)
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!
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.
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.
WHAT IF I AM EDITING AN HTML PAGE AND I WANT TO SEE THE ACTUAL NAMES IN THOSE LINKS, NOT THE UGLY BASE62-ENCODED HASHED IDs?
-- You can probably just USE the names, and "The HTML Editor of the Future" will do the hard work of substituting the IDs when you save the file later. (Computers can do this for us!)
-- In fact it will probably just add the IDs together WITH the names, for whichever tags where they don't already appear.
-- Until such an editor exists, a very simple script would do this.
WHAT PROBLEMS DOES THIS SOLVE?
- People can use any "DNS name" they want for their website. It will never be "already taken".
- There is no central "DNS server". No central authority.
- 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?
- Supports ALL PROTOCOLS. (Whichever addresses you put in your contracts... tor, i2p, ip, dns, freenet, etc.)
- 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.
- No more domain squatting. No more monopoly control over specific names. No more having to PAY for any name! No yearly registration fees, no ICANN fees, and no Namecoin purchase necessary. Your website also can't EXPIRE -- unless you put it in the contract that way, or unless we make it a feature of the system.
- Yet, paradoxically, you can still build up value in a specific name, and you can still sell that name and website later.