Better Name Service

Dillon Kellar
Mar 11 · Unlisted
this picture makes the article look more technical

I have believed for several years that we should be moving towards better proof of identity and that blockchain systems can be extremely useful for securing public key infrastructure. Using Ethereum, you don’t need verifiable maps or logs that require auditor networks for validation and you don’t need to trust any individual server or auditor. While it’s not technically challenging to build a system for mapping names to Ethereum addresses, a critical mass of users is necessary to make any such software useful in practice. In this area, ENS has done a fantastic job. Opera is apparently about to support ENS resolution of dapps and ENS now has experimental support for DNS.


Problems With ENS

While I think ENS is valuable as a demonstration of the potential for widespread use of blockchain systems, it suffers from some of the same vulnerabilities as DNS.

Smart contracts are not inherently secure, they just assure adherence to state management rules

The best thing about Ethereum is that you can write complex logic that will be verified by a global network of Ethereum nodes. Whereas systems with their own data structures and security models require auditing software specific to their services (such as CONIKS, DNS, Trillian), Ethereum is a ready-made global auditor for practically any program that can execute in a short period of time. This security model where the data providers and processors are not a major point of failure leads people to believe that if a system is built on top of Ethereum it inherently has excellent security. That can be true if you write secure software but it is certainly not the case if you build the vulnerabilities into the specification.

The first big web3 dapps should be substantially more secure than their web2 counterparts

Once a service hits a critical mass of users, it becomes incredibly difficult to replace. I would be severely disappointed if a large portion of the web’s security switched over to blockchain systems only to have essentially the same security models as their web2 counterparts. Decentralized blockchain systems allow verification without relying on authorities. Users should have the power to manage their assets and identities and perform moderation on services they own which others use. But they should not have the power to infringe on the security or assets of others.

The biggest vulnerability in DNS is not that a certificate authority serves you a domain certificate and tries to hide it from the rest of the network, so simply putting the records on a smart contract does not improve security in most cases.

The easiest attack for a CA to execute is to make a valid modification of a domain certificate in order to serve you data from an incorrect source. ENS has the same vulnerability, only with domains instead of name servers or certificate authorities.

Normally this wouldn’t be an issue because subdomains on the web are always owned by the second level domain. With ens, however, we are seeing a large number of services pop up using subdomains on their ENS domains as usernames. If this is used as the basis for a messenger, such as with Status.im, we will have moved to a better data processing and validation structure by using Ethereum without actually improving the security of the system as a whole.

Building vulnerabilities into our authentication systems is not the direction we should be going in as a community or as a society. Public keys should have a trustworthy management system where you do not need to rely on any third party to be honest in order to trust your key bindings.

I recognize that there could be situations where individuals use their subdomain keys for illegal or obnoxious purposes and that there may be consequences for the domain operators if they were unable to shut them down. Yet I do not believe the solution is to give domain owners complete control over child keys.


Beef

While my main issue with ENS is the security model, I also have some non-security related beef with it.

front beef

Why do I have to wait 3 days to purchase a domain?

There’s no real reason you should need to wait 3 days to buy a domain. If you buy a domain on Namecheap you get it instantly. If you register an account on Reddit, you get it instantly.

The obvious reason for the domain auction process is to prevent someone from purchasing all the short or valuable word domains, but realistically I don’t think it will prevent that except in very specific cases. I think it’s a bad value exchange to trade a little less spam for a lot less usability.

Short domains

ENS domains can not be less than 7 characters. Does no one else remember the good old days where people would battle over 3 character IRC names? I don’t either, but it sounded like a good time.

Hashed domains

The stated reason for hashing domains is to provide privacy but unless you use an exceedingly long domain name, your domain can be cracked in a very short period of time. Most domains only use a-z characters and uppercase characters are converted to lowercase in ENS. One 1080 can crack almost a billion sha3 hashes in a second. If you have ten 1080s you can crack all a-z domains up to 10 characters in 4 hours. Domains aren’t private if the vast majority of them could be cracked and published in a few days by someone with a little bit of money to throw away.

I believe (but am not certain) that the domain hashes would also allow you to register a domain on ENS, such as username.stateofus.eth (the status.im domain) and have it resolve on the primary ENS resolver. Subdomains are supposed to have their own resolvers but if you could get the client to query the owner of the full domain hash against the ENS public resolver rather than perform the proper lookup, you could create an invalid or duplicate entry. This isn’t really that big of an issue since clients can be expected to always do correct look-ups, but it seems like something that should be addressed (unless I’m completely wrong and this is not possible, I have not tested it).


Better authentication

We desperately need better authentication systems.

DNS is decent but it’s limited to domains and it doesn’t really prove much other than “the certificate authority says the key is x, and it is saying that to everyone else too (probably)” unless you want to run a home DNS auditor 24/7.

ENS is better but since domain owners can modify child entries, in order to validate an entry a client would need to look up all old transactions targeting a subdomain to make sure it has not been modified.

In my opinion, a secure registrar is one which guarantees that the current owner of a name (domain, subdomain, email, my little pony roleplay name, etc.) either is the original owner of that name or has gained ownership of it through the explicit approval of each previous owner.

Other systems like CONIKS, Trillian and the ContinuSec implementation of verifiable maps/logs are neat but they don’t work without service-specific auditors.

I want a secure, generalized authentication service that does not require clients, developers or anyone else to run their own auditing tools in order to trust the validity of entries.


Enter BNS (Better Name Service)

I put together a smart contract which I think is a good representation of what I believe blockchain name services should look like.

The name is just cheeky. I don’t have a research team or a leet group of cryptographers behind me, I just threw this together in two days and I’m sure it has substantial flaws. I certainly don’t recommend using it for anything important (not that anyone would) without a great deal more auditing and improvement, but I think it is closer to what is needed than ENS.

Links

No auctions, many TLDs

It seems like the issue ENS tried to solve with their auctions is people parking all the valuable domains. A friend of mine reminded me that when a new top level domain comes out for the web, it usually starts at a really high price and then gradually drops over time. So that’s what this contract does.

When a new TLD is added (which anyone can do for free) it costs 5 Ethereum to register a second level domain on it. Every 15000 blocks, which should be somewhere around once a day (according to my in-depth research, which consisted of looking at etherscan for 30 seconds), the TLD price drops by 25% until it reaches 0.01 Eth, at which point it stays there forever.

To avoid confusion with real top level domains, domains look like google@com rather than google.com. I considered using Oraclize or some other method that would allow a domain owner to prove ownership to the contract, but this could cause issues with domain transferal and would introduce a reliance on DNS, which we are trying to improve upon.

Infinite subdomains

You can create infinite levels of sub domains with this contract, but it will probably get expensive.

Storage

Similar to ENS, this contract supports key/value pair storage per domain/subdomain.

Content

There is an optional content property you can set on a subdomain/domain that lets you say “these are my bytes, they’re where I keep my cool stuff” if you have some IPFS/Swarm storage you’d like to share. Or you could set it a url or a base64 surprised pikachu. If you have a bunch of different files to share you can put those on subdomains or in your key value storage.

No refunds

Once you buy a second level domain it is yours forever or until you transfer it to someone else. The money goes to the smart contract and I keep it. I don’t want people to have any opportunity to get a refund from the contract because I believe that incentivizes buying as many domains as you can and trying to sell them, then getting a refund if you can’t. There’s also no market functionality on the contract. If you want to sell your domain go ahead, but this contract does not facilitate it (aside from offering the ability to transfer ownership). It would be pretty simple to create a marketplace auction.

Subdomain management

If the owner of a second level domain decides that the jerk in one of his or her immediate subdomains is getting a little too cocky or causing trouble with Johnny Lawman, he can delete the subdomain. You can not say John is Bob or Alice is Cindy, your only option is to delete the subdomain forever. No one else can ever have it, it belongs to address(0x01).

As the owner of a domain/subdomain you can specify whether or not to allow anyone to register child domains. Consider it a reversible vasectomy.

You can add owners of subdomains directly if they are not already taken, as well as set approved users who can register subdomains of their choosing, but you can not allow subdomains of your child subdomains unless you own those subdomains, and you can not modify their data storage. This way even if someone gets banned, they can still retrieve their data because no one else is allowed to ever delete it (take that, miners).

Character limitations

Domains can be any length, but they must be in lowercase (if they are in uppercase the smart contract will adjust it). Each domain level can have [0–9],[a-z],[-_] . No other chars shall pass.

The key/value storage doesn’t care about what you put in, put a Ξ, see if I care.

Conclusion

Definitely don’t use this code until and unless it has been more thoroughly audited, but also don’t use other insecure identity storage solutions. Come up with your own smoke signal ciphers and communicate through Google Maps. Have a chat behind your house. Exchange symmetric keys through handwritten letters. Don’t use insecure cryptosystems.

Unlisted

Dillon Kellar

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade