-
Notifications
You must be signed in to change notification settings - Fork 84
OT Replaces DNS
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:
1) 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.
2) 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.
3) 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?)
4) 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?
5) 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.
6) 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.
7) 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="SSK@GB3wuHmtxN2wLc7g4y1ZVydkK6sOT-DuOsUo-eHK35w,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.
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.)
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.)
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!
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.
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?
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?
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.
6) 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.
7) Yet, paradoxically, you can still build up value in a specific name,
and you can still sell that name and website later.