
Handshake: Decentralizing DNS to Improve the Security of the Internet - troquerre
https://www.namebase.io/blog/meet-handshake-decentralizing-dns-to-improve-the-security-of-the-internet/
======
comex
It still seems bizarre to me that this system lets people register arbitrary
TLDs. If nothing else, sooner or later a new ICANN gTLD will conflict with a
Handshake registration. At that point, Handshake will no longer be a backwards
compatible extension of the existing DNS, so systems will have to choose one
or the other. Maybe the Handshake authors think that when that day comes (and
it's probably not that far off), Handshake will already have achieved enough
popularity that operating systems and browsers will choose Handshake instead
of ICANN. Somehow, I doubt it...

Imagine IPv6, but if it was somehow designed to squat on top of the IPv4
namespace, so that switching to IPv6 would cause existing addresses to start
pointing somewhere else. That's pretty much the situation Handshake has chosen
to be in.

Not to mention that allocating TLDs

\- confuses non-technical users ("what do you mean, there's no dot in the
address?")

\- conflicts with the choice of most browsers to unify the address and search
bar (if I type _refrigerators_ and press enter, I want a search results page,
not the homepage of whoever registered the TLD 'refrigerators')

\- may conflict with other non-standard domain name systems, including
special-purpose TLDs like .onion – though they've at least reserved the
existing ones, so it would only be a problem for not-yet-developed systems

It's strange, because I want to support decentralized name systems, and
Handshake seems better designed than some of the previous attempts, but that
one decision makes it seemingly guaranteed to fail.

~~~
tialaramex
> I want to support decentralized name systems

This isn't a coherent thought, which illustrates why they fail. A name
_system_ is something you have exactly _one_ of, because otherwise they
conflict. To support more than one is to give up altogether, it might actually
be slightly worse than just not caring at all.

So you'd need to pick one and then, even if clearly better alternatives are
subsequently proposed, you _must_ stick by your choice or you destroy the
value of choosing at all. That's clearly a bad idea, you're more or less
guaranteeing a sub-optimal outcome for yourself.

~~~
lucideer
I'm not seeing any explanation behind any of your attestations. Are they
assumptions?

Saying conflicts are inevitable/unavoidable between name systems seems
simplistic: it's a problem to solve. Not necessarily easy, but I know of no
hard law making it implicitly insurmountable.

Why does changing name system destroy all value? Sure, changing _any_ system
is disruptive and can be relatively destructive; such changes must be weighed
against benefits of change, but I see no reason choosing generally better
alternatives must destroy all value.

~~~
tialaramex
The conflict is intuitively obvious. A name system maps names _to_ something.
If system A and system B have the same mapping, that's just the same system
under a different name. If they have different mappings they conflict because
the mapping will give me different results from system A versus system B. It's
that fundamental.

~~~
KomradeKeeks
The address bar in Chrome shows both the string as a potential search, and
URLs in recent history/tabs with that string. Why wouldn't a Handshake-
supporting browser do something similar?

------
funfunfunction
I love the idea but it seems like like a long shot to get the network effect
working in your favor instead of against you. You mention a bottoms up
approach and what happened in Catalonia but that is such a tiny percentage of
the population facing problems that most people will hopefully never face. How
does this go mainstream? Why should the average person care about a more
secure solution to DNS? Most people happily ship their data off to Google and
Facebook and are blissfully ignorant about the potential consequences. It
seems like you would have to make people care more about internet privacy
before something like this would work on a large scale.

IMO, it faces the problem that most crypto projects are running into; it might
be good solution, but the problem doesn’t effect the average person enough for
it gain mainstream traction.

~~~
troquerre
There are many instances where an intolerant minority is able to get a neutral
majority to adopt their will. Nassim Taleb describes this as the minority
rule. It’s the same reason why all lemonade is kosher*

A small minority of people NEED censorship-resistant and seizure-resistant
DNS, and the bet is that they can get the majority to adopt Handshake. The key
is that Handshake is backwards compatible with existing DNS, so for the
majority that don’t care, they can switch to Handshake without problem. I’d
also emphasize that in addition to the minority that absolutely needs it,
there are millions of prosumers who care about privacy and security as well,
as evident by how quickly Cloudflare’s 1.1.1.1 has grown.

On the point of Cloudflare, 1.1.1.1 often gets a lot of usage in countries
with strict DNS censorship. When Turkey took down twitter.com, people
literally spray painted 1.1.1.1 on walls since you could use it to get around
the censorship. OpenDNS got a lot of growth outside the US this way as well.
In both the case of Cloudflare and OpenDNS, they can’t promote the censorship-
resistant use case as strongly because they have a single IP. Handshake
doesn’t face the same restriction.

Eventually, the goal is to get browsers to adopt Handshake in order to reach
the late majority who don’t care either way, but that would only happen after
significant bottoms up adoption. At a certain point it’d make sense for Opera
and Brave to integrate Handshake, and then Firefox, Edge, and all the other
browsers as well.

*[https://medium.com/incerto/the-most-intolerant-wins-the-dict...](https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15)

~~~
funfunfunction
It’s true that a single static IP address is easy to block, but what is
stopping an oppressive regime from building tech specifically designed to
block Handshake? Correct me if I’m wrong, but Handshake still functions over
IP and as such a government could potentially block all IPs associated with
Handshake via similar mechanisms that are used to block a single IP. If there
exists some kind of public list of all Handshake resolvers, as, from my
understanding, there would have to be, they could very easily continue
censoring content deemed inappropriate. I don’t see anything built into the
core of this that will solve this problem. Oppressive regimes will adapt.

And DNS as it stands is fairly seizure resistant as long as you use secure
passwords and the customer services folks don’t get tricked into resetting
your account or something.

The vision is grand. I’m excited to see where this project goes and will
definitely be following along. Best of luck.

~~~
denton-scratch
As far as I can see, I could run a Handshake recursive resolver myself, either
for my own internal network, or I could publicise it.

It's not clear to me how a third party could verify that my resolver was
returning answers based on blockchain data, though. I suppose the blockchain
could be contrived to return DNSSEC signatures, which could in turn be sent by
the resolver; so if you trust the blockchain root's DNSSEC signature, then you
can trust an arbitrary resolver. But the article didn't mention DNSSEC, or how
you establish trust in an arbitrary resolver.

------
_wldu
I never imagined someone would write a recursive DNS sever in javascript. Have
they explained why they chose javascript? It can't perform well nor scale and
they even sort of admit that:

[https://github.com/handshake-org/hsd#unbound-
support](https://github.com/handshake-org/hsd#unbound-support)

~~~
QuicksilverJohn
Basically, only the root record parsing is done in JS and then passed to
unbound for resolution. Though it is possible to run a pure JS resolver, it's
not really recommended.

There's also a more portable authoritative & recursive [resolver in
C]([https://github.com/handshake-org/hnsd](https://github.com/handshake-
org/hnsd)).

Plus, the whole protocol for node communication and name resolution & proofs
is so simple, that it's pretty easy to reimplement in any language.

~~~
w8rbt
Right, thanks. And I hope my question does not sound too critical. I was just
genuinely curious why JS was used.

I think JS is fine for small to mid-sized tasks, prototyping and testing
ideas. However, for real DNS servers, used by a lot of clients, I believe C,
C++, Go or Rust would be an absolute requirement.

~~~
tynes
The JS implemention is a fork of bcoin, the JS Bitcoin full node and
production backend.

It binds to libunbound but you are right that you would want a lower level
language for it to be more scalable. There is a rust implemention work in
progress here:
[https://github.com/UrkelLabs/rsd](https://github.com/UrkelLabs/rsd)

There is also a C light client here: [https://github.com/handshake-
org/hnsd](https://github.com/handshake-org/hnsd)

For the consensus, there are C bindings for the cryptography and a workerpool
that really speeds things up.

It could also be possible to dump the Handshake zone into a zone file and
serve from behind unbound.

------
viraptor
> The likelihood of conflict is low even though conflicts can technically
> happen.

If registrations are random - sure. But isn't conflict pretty much guaranteed
since people will try to register all the big names?

------
hannob
"Blockchain-based alternative to CAs" has been discussed before there even was
the word blockchain (it was called sovereign keys, at least it's pretty close
to a blockchain).

I'd expect someone trying at least discussing why that didn't make it. Also
I'm really annoyed by the "there was a problem with CAs in 2011, this system
is really bad"-tune ignoring what has been changed since then. (E.g. the "You
don’t know who all these CA intermediates are" may be true, but that's your
problem, because you very well could know, the information is there.)

~~~
troquerre
Author of the post here. My aim was to keep this post focused and cover the
differences between Handshake and previous blockchain DNS attempts in a
separate post. The keyword here is attempts: previous projects like Namecoin
and ENS haven't really taken off. I think the reason has to do with the
underlying technology and the go-to-market strategy (or lack thereof) of the
projects.

On the technology front, Handshake is the only naming blockchain that's
launching with a light client that can resolve names. This may seem like a
small thing but it's actually a critical input to success — without a light
client, users would either need to run fullnodes (which no one does bc of the
terrible ux) or rely on third party services. Third party services provide
good ux but reduce the benefit of using the decentralized system in the first
place.

On the go-to-market front, the initial distribution of names is really
important. It's much more important than the initial distribution of something
like Bitcoin because names are non-fungible. They're digital real estate so if
a whale is able to bid up all the good names before adoption, there will be no
incentive for new participants to invest in the ecosystem (this happened to
the previous projects).

Handshake created a few GTM mechanics to prevent that outcome:

* The Alexa top 100k domains have been pre-registered, so that only those domain owners can register their names on Handshake

* Names are released for bidding over a 52 week period. If you hear about Handshake 8 months into launch there will still be a lot of good names available

* Auctions last two weeks and require locking up your coins, making it difficult to bid and win on a lot of names at once.

* Most importantly imo, Handshake coins are being distributed to developers, not investors. 70% of the initial Handshake coins are being airdropped to ~250k open-source developers. Basically, if you have a GitHub account with over 15 followers and an SSH key, you can anonymously claim Handshake coins. This is a no-strings attached giveaway so it will hopefully give developers a reason to check out the project, and it also makes it difficult for whales to buy up a lot of coins early on to outbid everyone.

~~~
hagreet
So, if there is a name that I would like I basically have to announce it to
the world and then enter into a bidding war with people speculating?

~~~
NetOpWibby
Yes

------
troquerre
Author of the post here. If you have any questions I'll be online for a while
to respond to them. We're serious about attempting to improve the security of
the internet, so criticisms are welcome too.

~~~
hlieberman
Isn't this just basically Namecoin but with venture capital money?

~~~
troquerre
Previous attempts at blockchain naming have basically failed, and there are a
few reasons why. I go more in-depth into why Handshake is different/may
succeed this time around in my comment here:
[https://news.ycombinator.com/item?id=21001806](https://news.ycombinator.com/item?id=21001806)

------
lostmsu
It would actually make sense to have ICANN create an official TLD for
Handshake.

~~~
troquerre
We've spoken with people involved with the ICANN and I think that'd be
unlikely. In a sense, ICANN is the incumbent that Handshake is trying to
unseat, so it's not surprising that they don't like it. There have also been
numerous alternative root projects in the past that all failed, so when ICANN
people see that aspect of Handshake they quickly dismiss it. Interestingly,
we've had conversations with Vint Cerf who invented TCP/IP and he actually
liked the properties that Handshake provides (wasn't a fan of the blockchain
implementation though). Vint proposed a system with similar properties in the
past as well: [https://cacm.acm.org/magazines/2018/12/232883-self-
authentic...](https://cacm.acm.org/magazines/2018/12/232883-self-
authenticating-identifiers/fulltext)

------
seamyb88
I'm not a blockchain expert (or DNS, for that matter), but my reckoning is
that alternatives to public-key infrastructure involving such things as
identity-based and attribute-based encryption are a more promising way to get
rid of CAs. Tackle it at the level of the trapdoor function, as this is, at
least, mathematically robust. The mathematics of networks is less so.

~~~
troquerre
The Innovators Dilemma provides a good framework for thinking through how it’s
possible for new technologies to unseat incumbent network effects. Basically,
the new technology needs to outperform the existing technology along a
dimension that a new user demographic cares about, but that most existing
users don’t care about. That’s how Instagram was able to gain traction in
spite of Facebook, and Snapchat was able to gain traction in spite of
Instagram. For Handshake, it can beat existing DNS along the dimensions of
security and censorship resistance, which I think might be enough to give it a
foothold to grow. But we shall see...

------
Avamander
Also posted on reddit with the owner trying to answer some questions:
[https://www.reddit.com/r/netsec/comments/d5iv4y/decentralizi...](https://www.reddit.com/r/netsec/comments/d5iv4y/decentralizing_dns_to_improve_the_security_of_the/)

~~~
troquerre
Author of the post here. The r/netsec community brings up good points. One
thing that's come up frequently is the question of trademark disputes.
Handshake _does_ have mechanisms in place to protect a good number of existing
trademarks (only the domain owners of the top 100k Alexa domains can register
their names as TLDs), and it also has mechanisms to prevent early squatting
through the 52 week period for name rollouts.

These mechanics protect trademarks in the short term, but in the long term
anyone can bid on an unregistered name in the open auction system that
Handshake created. My perspective on this is that there isn't an inherent
reason why a naming system needs to deal with trademark issues — there are
pros and cons to names being registered in an open auction, just like there
are pros and cons to Bitcoin being a store of value that's difficult to censor
and seize.

~~~
ocdtrekkie
There are very good public safety reasons to allow lifting domains from their
current owners. Like if someone owns Microsift and puts a phishing page on it.

What about botnet C2 servers?

~~~
xur17
This doesn't completely solve the problem, but the top 100k domains on Alexa
will be reserved for those domain owners (ex microsoft.com can claim
microsoft, google.com Google, etc).

------
jstewartmobile
No company in its right mind is going to trust its brand to this.

Megacorps want an administrative solution--a clear target they can throw money
and lawyers at if something goes south--rather than blockchain, where a
disgruntled employee can run off with the private key and hose the domains for
perpetuity.

~~~
troquerre
Author of the post here. I agree with you on this, at least in the early days.
I don't expect any major company to switch to Handshake or even adopt
Handshake. Realistically, adoption will happy in a bottoms-up fashion,
starting with people in the jurisdictions that need it most. For instance,
Spain shut down IPFS gateways when Catalonians used it to advertise the
Catalan independence referendum. If the IPFS gateway was on Handshake, it
would have been much more difficult to take down the gateways.

[https://www.reddit.com/r/ipfs/comments/728tt4/note_ipfs_gate...](https://www.reddit.com/r/ipfs/comments/728tt4/note_ipfs_gateway_blocked_in_spain/)

------
al_form2000
I find this trend of applications packing their own resolver concerning. If
nothing else, it widens greatly the attack surface to name resolution. I also
foresee mayhem with perimeter firewalls and stuff. It should be possible to
block this at the OS level.

~~~
_squared_
Mainstream OSs are slow to evolve. While I agree that embedded DNS resolvers
in browsers and the like should have an off switch, I think embedding in
widely adopted software is the only solution to push adoption of these new
privacy-focused protocols.

Pushing updates to ever-green browsers is the key to change how millions of
people use their computer - since browsing the web is almost all they do!

------
EGreg
But how does this solve the problem of Trust on First Use?

Blockchains can safeguard the integrity of the data, but how do we know that
painting in the real world corresponds to the token that purports to represent
it? How do we know that business on Google really is that business and not a
guy in their basement? How does Google or anyone really verify it, whether
they are a top-down corporation or a blockchain or a decentralized project
like OpenStreetMap?

~~~
tynes
Proof of Work solves that by preventing Sybil attacks - it's costly to mine
(which is equivalent to signing off on, because it wouldn't make sense to sign
an invalid block, you would get rewarded). It's the only signature scheme
known to be dynamic and allow for an arbitrary participant size. The point is
that you can trust the chain with the most proof of work. As long as you
maintain a diverse set of peers and validate blocks, you can know the state of
the network.

~~~
EGreg
It doesn’t solve this problem at all. The site says:

 _How do you know that Google 's public key is actually Google's public key?
When you make that first request to Google, an intermediate network may have
intercepted your request and returned a fake public key for Google. CAs
attempt to solve this problem. CAs are trusted third parties that verify the
authenticity of public keys for websites._

How does proof of work ensure that google.com really goes to Google and not
someone who paid $2,000 to mine something?

~~~
troquerre
A miner wouldn’t be able to do that. Only the private key owner of Google
could do that. At most a miner could do a double spend attack (would cost a
lot more than $2000), but that wouldn’t change the DNS record for Google.

~~~
EGreg
The question is how do you know that the owner of the private key is the
“owner of GOOGLE”. That’s what CA’s solve. Blockchain doesn’t solve this
problem.

------
gonational
Question to author: will it be possible in Handshake for the community to
agree to censor a domain via a vote of some kind?

(FTR, I hope not)

~~~
troquerre
There is no way to do that via the blockchain itself. Theoretically, the
community could hard fork Handshake to exclude certain names, but that’s
unlikely as it’s antithetical to why the community would use Handshake in the
first place. It’d be like if the Bitcoin community hardforked out certain
addresses in Bitcoin...

------
zimbatm
> Verify Your Identity to buy/sell

Are there any ways to acquire HNS without sending a photo ID to a centralized
party?

~~~
troquerre
In order to comply with US laws we need to verify people’s identity before
they can buy/sell HNS, but fortunately it will be possible to register names
without identify verification.

------
vinay_ys
Blockchain solutions in real world work because of people's ability to form
legally binding consortium made up of real business entities that have decided
to cooperate with each other.

Crypto backed distributed trust that blockchain brings into such consortiums
has no value other than superficial optics and hype novelty as of today. It
doesn't solve any real problems that isn't already solved by legal mechanisms.
To prove this, if you take away the legal mechanisms upon which the consortium
is built, the consortium will fail and blockchain won't be able to hold it
together.

For example, Bitcoin has value because masses trust they can convert it back
to fiat currency via a coin exchange. Coin exchanges are real business legal
entities that are subject to laws and regulations as they deal with fiat
currency. For the masses, these laws and regulations are what confer that
trust on those exchanges, not crypto.

It is best to think of bitcoin as a technical protocol but with very
interesting properties, technical properties, and that has certain
implications in real world – specifically w.r.t tampering and double spending
or theft fraud. But this by itself has no real world value without the legal
system backing its conversion to fiat currency. Without this relation to fiat
currency, the technical properties are worthless on their own.

Similarly, handshake blockchain has no real world value unless a legally
recognized consortium emerges to add value to it in real world.

Using bitcoin metaphor, instead of real world fiat currency it is real world
names, trademarks that gets "converted" to digital names on this handshake
blockchain that gives this blockchain any value. Once you have a
trademark/realname "converted" on this blockchain, your ownership cannot be
"stolen or double-spent" etc. That's the intrinsic crypto property of the
blockchain which has some real-world value.

But this name "conversion" has to be done by "exchanges" which are real-world
business entities to which laws can be applied.

Without this being baked into the system, this is dead on arrival.

------
sebastianconcpt
_Handshake is a blockchain protocol that aims to solve the issue of trusting
hundreds of CAs. It 's a protocol that's similar to Bitcoin, except instead of
using coins as money, you use Handshake coins to register names on the
Handshake blockchain. These names are top-level domains (TLDs) like .com,
.org, .net. Handshake decentralizes the root zone file, which is the ICANN-
controlled file that determines who owns what TLD. Anyone can register their
own TLD on the Handshake blockchain._

We need some form of DNS decentralization not only for security but also to
improve availability.

------
nikolay
Sorry! I'd rather trust Mozilla than some craptocurrency/bullchain company
trying to make money out of everything. I don't want to be dealing with
speculators and people after the get-rich-quick scheme masqueraded as a
"change everything and solve all your problems" solution!

~~~
digitalhans
[https://www.debian.org/News/2019/20190329](https://www.debian.org/News/2019/20190329)

[https://news.softpedia.com/news/gnome-and-gimp-
receive-400k-...](https://news.softpedia.com/news/gnome-and-gimp-
receive-400k-from-handshake-decentralized-certificate-authority-522218.shtml)
[https://www.gnome.org/news/2018/08/gnome-foundation-
receives...](https://www.gnome.org/news/2018/08/gnome-foundation-
receives-400000-from-handshake-org/) [https://www.fsf.org/news/free-software-
foundation-receives-1...](https://www.fsf.org/news/free-software-foundation-
receives-1-million-from-handshake)

~~~
nikolay
I don't care about their lame Indulgence attempt and portray themselves as
somebody different from the stinky HODL crowd!

------
seibelj
Are namebase and handshake related? How is handshake.org different?

~~~
agrinman
namebase is to handshake as coinbase is to bitcoin

~~~
QuicksilverJohn
Yep. And it's also a DNS registrar.

------
airstrike
How about the risk of parking TLDs on Handshake? Say, by taking every
.{lastname} out there just in case someone wants it in the future...

~~~
igliu
Could certainly happen, but there's a couple mechanisms that mitigate this:

1) The network will only allow you to bid on a name if it has been at least
`hash(name) % 52` weeks after mainnet launch. Squatters cannot purchase all of
the good names on day 1.

2) The network limits the total number of domain renewals that can occur each
block. Eventually this will lead to fee pressure and make renewing 10,000s of
domains expensive for squatters.

3) It's possible to atomically trade names for coins on-chain, so squatters
that self-custody will likely do this to make selling their names easier. The
names will end up with someone that actually uses it

~~~
hagreet
So my domain will become more and more expensive? Great.

------
vectorEQ
isn't dns already decentralised? (apart form everyone basically using the same
server(s) / google ?) you can just set up your own dns if you want to have
your own mappings of ip->dn and vice versa. just set your dns to the server
you prefer?

~~~
topranks
The root DNS servers are distributed widely and operated by different
organizations.

But it’s a single root, and it is administered by ICANN directly who decide
who can be a root name operator. So there is central control there.

~~~
vectorEQ
this does not stop one from having their own dns server and resolving what
they like. the protocol itself has no owner, just a specified way of
functioning. one can choose what dns server to use, and how to configure that
to respond.

building some sort of overlay network on top of the internet has been done
before (.onion anyone?).

How would this improve upon such a scheme for example? I really don't think it
adds anything but the word 'blockchain' to the equation, and i honestly don't
think that adds anything in the way of security.

additionally, to revoke ones domain name to say, resolve to another host,
changing hosting provider for example, would seem impossible in an immutable
blockchain. Would that result in forks or in namespace pollution?

------
tanchoux
How long have we wait after registration ? It seems interesting...

~~~
troquerre
Handshake is currently in testnet and the auctions last a few days, but on
mainnet the auctions last ~2 weeks. Names are open for bidding for the first 5
days, and then the next 10 days are for bids to be revealed.

