handshake-org / handshake-org/hsd

Can not claim reserved name from .org .info and some other TLDs

Open
#399 3 comments 0 reactions 0 assignees View on GitHub
FAQ (Don't close)
Dominant language
JavaScript
Stars
2.1k
Forks
306
PR merge metrics
No merged PRs in 30d

Description

Importing discussion from:
https://github.com/handshake-org/handshake-org.github.io/issues/59#
and
https://www.reddit.com/r/handshake/comments/fnzwai/help_with_name_claim/

### Short answer why these CLAIMs are rejected by hsd:

It's because the TLD operator is using a weak key to sign their zone.

### Solution:

.org nameholders need to contact [Public Interest Registry](https://en.wikipedia.org/wiki/Public_Interest_Registry)

.info nameholders need to contact [Afilias](https://en.wikipedia.org/wiki/Afilias)

...and demand that these essential internet infrastructure custodians upgrade the security on their DNSSEC.

### More details:

Handshake reserved name claims are DNSSEC proofs that are submitted on the blockchain. They consist of a chain of signatures starting with the ICANN root zone, include your TLD and finally a TXT record in your own domain. Each of those signatures may have a different key type, depending on the operator of a particular zone.

Certain key types are considered "weak" if they include weak hash functions like SHA-1, and they are therefore not valid in Handshake reserved name claims, because it would be irresponsible to allow it.

Read: [SHA-1 is broken](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)

The relevant code is in the `bns` module here:

https://github.com/chjj/bns/blob/03b0ea5e7587774c0c3ad363f094a069acc1e60b/lib/ownership.js#L535-L537

and

https://github.com/chjj/bns/blob/03b0ea5e7587774c0c3ad363f094a069acc1e60b/lib/ownership.js#L590-L591

The actual consensus rule was deployed in hsd here, just before mainnet launch:

https://github.com/handshake-org/hsd/commit/05a232294949f84a6d909b052eef2b9faeb3953f

### Is my domain valid?

There are many web-based tools to inspect DNSSEC, consider this example for `blockchain.info`. There are green lights all the way down indicating a valid DNSSEC chain, however you can see the key type in the .info zone uses SHA-1.

https://dnssec-debugger.verisignlabs.com/blockchain.info

![Screen Shot 2020-03-24 at 8 22 54 AM](https://user-images.githubusercontent.com/2084648/77425284-dee98280-6da8-11ea-9223-183ab3129771.png)

Here is what a strong DNSSEC chain looks like:

https://dnssec-debugger.verisignlabs.com/crypto51.app

![Screen Shot 2020-03-24 at 8 25 48 AM](https://user-images.githubusercontent.com/2084648/77425552-4bfd1800-6da9-11ea-84df-116f9169792f.png)

The owner of `crypto51.app` was able to submit their DNSSEC chain to the Handshake blockchain and claim their name `crypto51` [in block 2350](https://shakescan.com/transaction/905b88f4c2d73fc6d383559fa985ac0a7819f472855b99b6fb1049b33823f7d3)

### Verbose details for super-nerds

Here's the DNSSEC chain for `crypto51.app`:

```
--> dig crypto51.app TXT +dnssec +trace @1.1.1.1

; <<>> DiG 9.14.6 <<>> crypto51.app TXT +dnssec +trace @1.1.1.1
;; global options: +cmd
. 3975 IN NS h.root-servers.net.
. 3975 IN NS i.root-servers.net.
. 3975 IN NS j.root-servers.net.
. 3975 IN NS k.root-servers.net.
. 3975 IN NS l.root-servers.net.
. 3975 IN NS m.root-servers.net.
. 3975 IN NS a.root-servers.net.
. 3975 IN NS b.root-servers.net.
. 3975 IN NS c.root-servers.net.
. 3975 IN NS d.root-servers.net.
. 3975 IN NS e.root-servers.net.
. 3975 IN NS f.root-servers.net.
. 3975 IN NS g.root-servers.net.
. 3975 IN RRSIG NS 8 0 518400 20200406050000 20200324040000 33853 . Pts3iS9X02Jg5JpFi3qJfvD9J/zSBIMkk4aprpCDqmR/WU4Qrh7FyL71 jqmhMdpMoSINtEzWe+6cgEcOwnuRl3ptY9k1t1fjJVuRVdeBUkYRqhba Vtps/udDv+qFBM4NvMGMyflsxUkiK5Qcr2ZZb3ztoTTzvxLicY9UPVlD jVOq0T6/29cAI2zZPifkI/wy6IeCIiHoZfXZ8AIFSxAsskuE2b3zUCna 1VCuDneOWdlRBtiPKtOE4WXaU/GzcyNBMOSpDMThGcCmeS18mVT1Lzq6 4D9eZCubHfQVXzcGfakbB5RV6hdQSL0UnN6c9vf0jiUyXHLf7gxL1dld 1P/wBg==
;; Received 717 bytes from 1.1.1.1#53(1.1.1.1) in 4 ms

app. 172800 IN NS ns-tld2.charlestonroadregistry.com.
app. 172800 IN NS ns-tld4.charlestonroadregistry.com.
app. 172800 IN NS ns-tld3.charlestonroadregistry.com.
app. 172800 IN NS ns-tld1.charlestonroadregistry.com.
app. 172800 IN NS ns-tld5.charlestonroadregistry.com.
app. 86400 IN DS 23684 8 2 3A5CC8A31E02C94ABA6461912FABB7E9F5E34957BB6114A55A864D96 AEC31836
app. 86400 IN RRSIG DS 8 1 86400 20200406050000 20200324040000 33853 . zqX6tuE67Rfh0aIYrCMUps3pcYYjuufF/OaI9ssudIxu6O4H6NayrS17 2reJZ94zxvkRBFDGJWe/LCoYCKgkxbdkcTmaAYMQ5+VCp+ptf0XsZjI6 Cx+KYePPtBIOQtlcypE2hFoDmW0chYazYfH55kPddl0PB6MctWP72lE/ ujni6czFk3PzaKK6pQKUZQeg4qQxQp4QM36mKB+2xqFkuBkuDnjrDqRb Lc5WyFXehfOnrztvWdKLgNGUURT8VYsSH0J4oycJ0KJTN2q76PKFeXFT hdf5mleXo+/HaQRe3e0BLgyaj0zvqOb6DxK4Ozly2sQEAdpgFhH1puSN 3zhFbw==
;; Received 760 bytes from 199.9.14.201#53(b.root-servers.net) in 14 ms

crypto51.app. 10800 IN NS beth.ns.cloudflare.com.
crypto51.app. 10800 IN NS theo.ns.cloudflare.com.
crypto51.app. 3600 IN DS 2371 13 2 7DB3A400A7A8B31C53384D951AE860F3C220D4A095524BDBBC4CEA6F E2572E4D
crypto51.app. 3600 IN RRSIG DS 8 2 3600 20200412144213 20200321144213 16930 app. dTFc1dRdKMh775YKel3AoegBzVlkabtC1sJtk7xJvYSIXRIwKbjoSlEX FqAcALCDsGblCdQFOuZ32UcTOhMMIllG971HR8dxdpqaT7SCLbvBAY/w 9tL/AgDAptLH9bShUxd+nv7MHg2uv2TRC2sgxPU+Z+Bmx0P/htG0JWws imQ=
;; Received 307 bytes from 216.239.32.105#53(ns-tld1.charlestonroadregistry.com) in 46 ms

crypto51.app. 300 IN TXT "brave-ledger-verification=2f0f1d9999addc94f42dcb69e94a0ecffb5c2506bb7f65dbaa716fd86248fdb3"
crypto51.app. 300 IN TXT "hns-claim:aakhjyfr2yt6fhk7mj4s77mdonvoqg6z2yzp4oblaeaaaaaaaaaklzaororjdpl6qzexi75h7ofhv447lownw5btzuxvs4ibaaaaautcqf3q"
crypto51.app. 300 IN RRSIG TXT 13 2 300 20200325132755 20200323112755 34505 crypto51.app. ric+Nk578JCskcRhDOIrOcmj3lZ3w1AXZvRWX6dkJqoAJaeYILTcflVy Jq3+VVDpaUELf2qpojLDlx3T5APwIg==
;; Received 383 bytes from 173.245.58.103#53(beth.ns.cloudflare.com) in 7 ms

```

Contributor guide

Open the contributing guide

Research direction

Start with the linked bns/lib/ownership.js locations at lines 535-537 and 590-591, then review hsd commit 05a232294949f84a6d909b052eef2b9faeb3953f for the deployed consensus rule. The issue does not define a code change or a test that would establish completion; it mainly documents DNSSEC key-type restrictions and external contacts for affected TLDs.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
networking, security
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.