search

handshake-org / hsd

Handshake Daemon & Full Node
Other
1.92k stars 279 forks source link

Permissionless claims for reserved names #21

Closed chjj closed 6 years ago

chjj commented 6 years ago

It's time to start redesigning the claim system to be completely permissionless. The CLAIM covenant should take a DNSSEC proof, stemming from the ICANN KSK (2010 for now, including support for 2017 when the DNSKEY RRSIG finally rolls over), all the way down to a final TXT record which commits to an address. The output's address must be equal to the signed TXT record. This allows any reserved name nameholder to claim their name in a decentralized way by adding a TXT record to their name's zone.

The tricky part comes when we have to maintain the root zone. We could devise a system where, prior to the claim of root zone name, anyone can publish all records for the referral of any name in the root zone file. This would keep the existing root zone up to date until the nameholder claims their name. This is tricky, as it would require the chain tracking signature timestamps, ensuring that no one could revert the data to the older state.

The problem: glue records in the existing root zone are unsigned. There's currently no way to prove that a server actually serves a specific zone.

So, if we can't do that, we have a plan B: if the resolver receives an absence proof for a name in the existing root zone (say, com is currently unclaimed), the resolver does a validated resolution to get the referral for the name, removes ICANN's signatures and replaces them with our own. This will allow the root zone to transparently roll over as more TLDs claim their names on handshake.

Claim Design

I've laid out some simple design ideas for the claiming process...

Required data for claiming google.com (example)

Zone 0 ()

Zone 1 (.)

Zone 2 (com.)

Zone 3 (google.com.)

Average Rdata sizes with RSA and SHA256

Size with implicit records (best case):

Size without implicit records (best case):

Size Notes

In reality, due to massive RRSets of DNSKEYs, this will probably range from 3kb - 10kb. The first two RRSets for com alone are 2157 bytes! Due to the nature of DNSSEC, the entire RRSet must be present.

$ dig.js @a.root-servers.net . DNSKEY +dnssec +nord | grep rcvd
;; MSG SIZE  rcvd: 1414
$ dig.js @a.gtld-servers.net com DNSKEY +dnssec +nord | grep rcvd
;; MSG SIZE  rcvd: 743

Finally, the final TXT record proof may be large if the nameholder doesn't have direct access to their ZSKs and also currently has a number of TXT records already setup. =/

Algo Notes

Support only the mainstream algos. Having algo bloat in the protocol is a disaster and creates more attack vectors. I'm sure you'd be hard-pressed to find anything currently in the wild which uses edwards curves or GOST.

Bcrypto supports RSA, P256, and P384 through openssl, and ed25519 through elliptic. Node.js only recently began building with a more modern openssl which exposes the new RSA/EC api. For safety, we may need to require the full node to only successfully boot on node.js >=10.0.0 (for the people who really want to run on older versions, they can modify the boot code, but we shouldn't support it as a feature). The bcrypto EC and RSA code should also be audited for buffer overflows and other bugs.

If anyone finds a single name on the reserved list that uses DSA, ed25519, or ed448 and only that algo, we should support them after all. In my own experiences wandering/digging around different zones, I have yet to see a single DNSSEC setup which uses these algorithms.

Proof Notes

Signatures

DNSSEC signature timestamps will have to be validated with MTP. They also expire, so that has some concerns for the mempool. Realistically, we could probably get by without validating the timestamps at all. It's unlikely someone would have an hns-claim record for their name before HNS is even launched or announced.

TXT records

Require TXT records for the final commitment. Have a TXT record commit to an address. Using TXT records is necessary for one major reason: a lot of the name owners on the top 100k may not have direct access to the ZSKs. Most every registrar's interface allow users to add arbitrary TXT records. This allows them to create a valid proof without having direct access to the private key (or presumably will allow them once their tld/registrar supports dnssec).

Simplicity

The DNSSEC proofs will be required to be extremely simple. It must be a simple DS->DNSKEY chain for each zone cut. Nothing fancy, no CNAME glue as that would allow people to steal names, and no wildcards for simplicity.

Proof Compression

DNSSEC proofs can be compressed. For a lot of RRSets, we don't necessarily care about a good portion of the data. Say we only one one record from the entire RRSet -- depending on how the records are sorted, any record before our desired record could be excluded from the proof. In its place would be the serialized state of the SHA1/SHA256 hash up until that point. I figure this could reduce proof size by 50% or so.

chjj commented 6 years ago

Note that we're also fairly lucky: although ICANN hasn't officially switched to KSK-2017, they have published it. Presumably it will be good for at least 5+ years, which means we're more than capable of including it as a consensus rule (our claim system is only supposed to be active for 3 years anyway).