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.
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.
>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.