I wish there was wide support for public-key-addressable servers (like tor adresses). It won't solve the issue of memorable names, but it could solve this bootstrapping problem.
Perhaps le should look into encorperating tor into its domain verification process.
“[…] you cannot have a namespace which has all three of: distributed (in the sense that there is no central authority which can control the namespace, which is the same as saying that the namespace spans trust boundaries), secure (in the sense that name lookups cannot be forced to return incorrect values by an attacker, where the definition of "incorrect" is determined by some universal policy of name ownership), and having human-usable keys.”
Zooko's conjecture predates the invention of Bitcoin, and the article goes on to explain that blockchain-based systems can in fact have all three properties.
It's not that anything in the verification protocol needs to be human-readable, it's that domain names themselves need to be human-readable and therefore can't just be derived from public keys. Which means you have to have some kind of system for deciding who controls which names, that doesn't just come down to who possesses a particular key. Zooko conjectured that this couldn't be done in a way that was both decentralized and cryptographically secure. He turned out to be wrong about that, although the DNS that everyone actually uses remains centralized.
The current CA system is horrendous in its centralization. It is completely possible to make a new mechanism using hashed-addresses and using traffic + user choice as the allocation mechanism for namespaces.
Instead of namespaces being fought for financially, users assign namespaces to site addresses (hashes) which represent a pub key of a keypair and identity of a server. The namespaces, say “search” is then assigned to the address hash with the most users by default. If a user likes a different one, they link the “search” namespace to a different hash and that counts as a vote for that location being the default.
This can be done using just traffic as an indicator for the defaults, in the event unique humanness cannot be established properly for an identity.
One summary of a frictionless scheme without central control that circumvents just about every shortcoming of the current system, and has all three properties.
There are other schemes, btw.
Also, in the event it isn’t clear: tls comes natively to this scheme because the addresses are pub keys. There can’t be a mitm for this scheme unless they have the priv key, or find a way to direct traffic through them and acquire a majority stake for a namespace and phish the original site. Whoever has the priv key controls the properties of the address hash, which is where all the records go.
This would make the internet significantly more democratic and less prone to bad actors. It would eliminate domain name squatting completely, and would enable new technologies which more closely match a namespace than old ones to have a chance, promoting innovation and meaningful competition.
“Everything” wouldn’t break; the most popular address is the one that gets the name. It means businesses and admins would need to put in the work to have a good product instead of getting lucky / having a ton of money to grab a name. Most likely, once a popular name is defaulted it will never change since this system has a “snowball” effect, but if a ground-breaking innovation occurs, then it would have a chance of taking the name.
Anyone that manually sets a name to an address is unaffected by the default setting. Only people that haven’t overridden the default are impacted. Most people would likely not even participate in this mechanism of “voting”, so it would be a smaller group that I assume is more involved that directs defaults.
Nothing is perfect but I think this would have significantly better results for humanity as a whole once it is matured than the current system.
Additional note: For anything programmatic / apis / etc, the address hash can just be utilized to connect systems. The address hash is not an IP address. It is a record set that can only be modified using signed messages, where the latest signed message determines what is in the record — this is where a record for, say, another IP can exist. Or a record to another address hash, etc. This record set could operate basically the same as current records for domains.
I explained that in the post. Namespaces / domain names / whatever you want to call them are set by individual users. The act of setting a namespace, ie binding “search” to whatever google’s hash is for example, contributes a “vote” to make that the default address for “search”.
Traffic can also contribute towards the count, either method would eventually settle on accurately capturing the will of people, but I would have to think about the mechanism for measuring traffic in a statistically accurate / honest way with a federated system.
You can measure users if users also have an identity bound to a key pair, with a mechanism to have attestations to their identity. In other words, the role of a CA shifts to making attestations that a pub key belongs to a unique individual. With that modification, it becomes possible to use their signature towards voting on which namespace operates as a default binding for an address hash.
This mechanism is very feasible when connected to a larger system involving federated identities, and a trust matrix where users decide which authorities they accept for identity validation (or any other attestation). Binding a physical identity to a digital one has a significant number of additional benefits, and it can be done such that anonymity is preserved via sub identities with verified claims.
When you connect to the service, the client tells the server which public key (key A) its expecting the server to prove that it has ownership of.
If the key A is still valid, the server can use the corresponding private key to sign a challenge.
If the key has been rotated out, the server instead presents the new key, and a signature. Eg, the server responds by naming key B, and presents a certificate of key B, signed by key A (the presented key). Instead of just a single key rotation the server could present a chain of certificates from A to B to C (the key the server wants to use). And optionally, a message saying "from now on, please make further requests using key B as key A has expired".
If the key is compromised, there’s two ways the key can be rotated. Either the key is updated upstream (in the dns record or through an app update or whatever). Or the next request uses the compromised key, (and could be MITMed.) The server responds with the new signed key. And requests after that will be safe.
It’s not perfect - it has some properties from TOFU systems. And it expects the client to cache key material. (It’s not stateless like tls). But I think it would be a pretty workable system.
DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example.
I suspect Microsoft would also have trouble taking control of a domain registered under a gTLD run by a company based outside the US, but it would be interesting to see how the agreements between the gTLDs and ICANN would work out in practice.
No, the US could not do that and there is multiple reasons for it. The root zone is rather special in that operating system semi-hard code the root servers. The operating system also have full control here and the number of name servers at the root zone changes very slowly. Operating systems developed by people not bound by US courts could just ignore it.
The other reason is political. If they were to cut out eu or asia from the list then the risk of a split would increase massively. It would be suicide. If they did that people might even split internet further by splitting iana (Internet Assigned Numbers Authority), in which case a computer in EU would be unable to communicate with an computer in US, and then the concept of a global internet would no longer exist. A split is a exceedingly dangerous concept.
Hints are used by the bind resolver software. It hard code the A -> M root servers and use those to initialize a cache. Naturally bind developers could change this behavior, and in the case that none of the hints works, the current behavior is to use a static compiled list that the software also include.
>DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example.
What? Obviously they could. ICANN is subject to US law.
Perhaps le should look into encorperating tor into its domain verification process.