[huggingmouth]

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.

[teddyh]

“[…] 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 Wilcox-O'Hearn: https://en.wikipedia.org/wiki/Zooko%27s_triangle

[ameliaquining]

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.

[huggingmouth]

I don't think we would need to deal with zooko's triangle in the case of automated systems like let's encrypt. Human legibility need not apply.

[ameliaquining]

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.

[survirtual]

Actually, you can.

[survirtual]

I like the downvotes here for stating a fact.

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.

[mhio]

So one day, the "search" default moves to the most popular and everything breaks? based on the amount of traffic generated for the other "search"?

Do you have more detailed write ups of that or the alternate schemes, at first take that sounds horribly flawed.

[survirtual]

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

[mhio]

The default is kind of like using top result of a search as the owner then? But I guess you want to count the number of real people who "favourite" a name > hash mapping.

You would need a consistent "easy" name as well at some point though, like a bank for example, can't use a name that could one day change for people who haven't bothered to default it.

Another issue might be names for the smaller, but very long tail of the internet, which would be open for abuse. For example a name could come and go with a social media post that gains traction, which would far outweigh the regular traffic for a name.

[ameliaquining]

How exactly do you make the addresses meaningful to humans if they're public keys?

[survirtual]

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.

[ameliaquining]

The thing being described here isn't really an address system. The point of addresses is that they're supposed to be stable; I want to know that I can go to google.com and know that the thing on the other end is controlled by Google and not some other entity. This is a lot more important than being able to look up "search" and know that the thing on the other end was chosen democratically rather than auctioned off. If the thing I want is to connect to one particular entity, then under this system the only way I can do that with confidence is by getting their public key out of band, which is deeply inconvenient and the whole problem that domain names were invented to solve.

Registry operators can also hijack domain names, of course, but they have an economic incentive not to do that (except in cases like malware C&C domains that don't affect legitimate users), because their job is to ensure that the whole system of stable addresses keeps working, and failing to do that would undermine confidence in the whole thing. A public vote doesn't have that incentive alignment; anyone who bothers to explicitly configure their system in this way, is fairly likely to be someone who'd join a campaign to hijack a name for the lulz or to make a political statement, at the expense of usability for regular users.

It's true that if you have human-meaningful domain names, then some of them will be more desirable than others, and anyone who can get a good one, or who can distribute good ones to those who want them, is thereby in a position to collect a certain amount of economic rent. Which isn't ideal. But this is all a second-order consideration at best; it's a side effect of the goal of stable addresses, which is the important part.

[Dylan16807]

You're punting the problem. You can't securely and objectively measure users and traffic.

[survirtual]

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.

[Dylan16807]

Now you're farming out to another "larger system" to ensure that the keys are real people.

How does that system ensure things, and why can't that system do domains directly?

> a trust matrix where users decide which authorities they accept for identity validation (or any other attestation)

So if I tell someone my "domain name" I won't know what site they'll actually get because it's calculated per person?

[hn_go_brrrrr]

How do you handle key rotation?

[josephg]

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

[dolni]

This falls apart if keys are ever compromised.

[josephg]

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.

[Zamicol]

Publish merkle roots on global ledgers like blockchains.

[withinboredom]

Handshake (namebase.io) comes to mind.