chjj
ownership: upgrade sha1 key algorithms
These changes allow a TLD owner who is stuck with a RSASHA1 key in the root zone to claim their reserved name on Handshake using the same RSA key but with SHA256.
Usage would be exactly the same:
$ bns-prove -b -K ~/Desktop/work/bns/test/data weakkeytld "hello-world"
Upgrading key algorithm for key ID 3810
AgMAADAAAQAAKjAARAEBAw1P1xREnYz8zP2rpSxk1j46...
The output of this example proof can be seen here: https://gist.githubusercontent.com/pinheadmz/ac9e30c50ff1630404d7885a8d2303b4/raw/511e34c926c31e77786215aaea5c2891e610fdfd/upgraded-key-claim-proof.txt
Notice in the TLD zone are two identical DNSKEYs but with different algorithms. The DS in root commits to the key with the SHA1 algorithm (5) but we sign the DNSKEY and TXT RRsets with the upgraded key SHA256 (8).
This example was generated with a custom root resolver and local nameserver to simulate a HNS mainnet claim.
From the Handshake whitepaper:
During our analysis of the root zone file, we discovered that a significant majority of domains use SHA1 for RSA signatures and key fingerprints. This is unfortunate, as SHA1's security against collision resistance was recently compromised[shattered]. Our consensus rules must disallow for the use of insecure algorithms, like SHA1, even with existing DNSSEC setups.
As a result of this, in order for an RSA-SHA1 nameholder to claim their name on the handshake blockchain, they must upgrade their key-signing key to at least RSA-SHA256 before creating an ownership proof. Unfortunately, to accomplish this, the nameholder must contact their parent zone and request that they sign off on a new key.
With this in mind, we must consider the possibility that ICANN may become uncooperative and refuse to sign a higher security key for an existing nameholder. If this were to happen, RSA-SHA1 root zone names would be unredeemable on the blockchain. To mitigate this attack, our DNSSEC ownership verification algorithm implicitly upgrades RSA-SHA1 keys to RSA-SHA256, allowing a reserved nameholder to publish the same RSA key in their own zone with a differing algorithm field (RSA-SHA256 or RSA-SHA512). This allows the nameholder to bypass ICANN's root zonefile update process when creating the necessary ownership proof.
Fixed the KSK issue and also added a test mode for bns-prove itself:
bns-prove --test -K ./test/prove-util weakkeytld "hello, world!"