Using BIP44 wallets for DNSSEC keys

[pinheadmz]

Handshake users should have control over their own private keys for the blockchain, backed up by a BIP39 seed phrase and derived using BIP44 (with purpose 44' and cointype 5353'). It would be convenient if we could extend this model for the DNSSEC keys that TLD owners will inevitably generate as well.

Unfortunately ECDSA (with curve secp256k1) is not a standard DNSSEC algorithm. However, ed25519 and ECDSA using curve P-256 (aka secp256r1) are: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

SO, we must be careful mixing cryptographic algorithms together, but if we can very intentionally keep the private keys separate, we can do it. I propose using a new BIP44 purpose with value 53' for DNSSEC key generation.

I think we can continue to use the ECDSA/BIP32 derivation algorithm to generate keys as needed, if we use hardened derivation only (which incorporates a hash) then there shouldn't be any crazy wallet seed risk. We can even create "accounts" from name hash and auction start height, then derive new keys from that account if we ever need to rollover. There wouldn't be a blockchain to recover from but a wallet could make a DNS request to find the current DS record and then regenerate keys to discover its "index".

This HIP would enable some really cool features, for example: Bob Wallet could easily support signed zone file management under the hood, obfuscating DS record and DNSSEC key storage away from the user. Public servers (like shakedex and even the block explorers) could be added as options into bob wallet.

User Interface could be this simple:

• win name in auction
• select public nameserver from drop-down menu (Kyokan, Impervious, Shakedex, Namebase host these)
• add subdomain A records in bob modal
• click submit:
  • bob generates DNSSEC keys using this derivation scheme
  • bob inserts DS record and NS record (for selected nameserver) into HNS root zone and sends UPDATE transaction
  • bob uploads signed zone file directly to selected nameserver

Example implementation:

'use strict';

const hsd = require('hsd');
const bns = require('bns');
const ed25519 = require('bcrypto/lib/ed25519');

const mnemonic = 'zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong';
const master = hsd.HDPrivateKey.fromPhrase(mnemonic);

const recv0 = master.derivePath("m'/44'/5353'/0'/0/0");
const ring0 = new hsd.KeyRing({privateKey: recv0});
console.log(`\nHandshake receive address: ${ring0.getJSON().address}`);

const name = 'handshake';
const nameHash = hsd.Rules.hashName(name);
const height = 78000;
const dnssec = master.derivePath("m'/53'");

// Derivation path will be more elaborate based on nameHash.
// `priv` also needs to be checked for validity in ED25519
// According to:
//   https://github.com/satoshilabs/slips/blob/master/slip-0010.md
//   "For ed25519... every 256-bit number (even 0) is a valid private key."
const priv = dnssec.derive(78000).privateKey;

const zsk = bns.dnssec.makeKey(
  name + '.',
  bns.constants.algs.ED25519,
  priv,
  bns.constants.flags.KSK | bns.constants.flags.ZONE
);

const ds = bns.dnssec.createDS(zsk);

console.log(`\n${ds.toString()}`)

Output:

Handshake receive address: hs1qy2s63vumtnv8d4twkg9lakh62qm7xydlcgqa5p

handshake. 172800 IN DS 7007 15 2 C50BD47A2B9F8EAE107F4221B4DE7DA8C5005594B674464083215A3B 5AE269D6  ; alg = ED25519 ; hash = SHA256

[buffrr]

Having support for nameservers/signing with bob wallet would be a nice use case for this. One issue with keeping DNSSEC keys completely offline is you have to increase the signature lifetime otherwise it wouldn't be practical

Assuming bob signed this zone with signatures valid for two years:

letsdane.               300     IN      A       157.230.75.71
letsdane.               300     IN      RRSIG   A 15 1 3600 20230816055636 20210808025636 27214 letsdane. [omitted]

_443._tcp.letsdane.     300     IN      TLSA    3 1 1 51A908C93287B3EA15BF58CA2C0BA36058FA20E33B9BEB8068433B98 6EA4843B
_443._tcp.letsdane.     300     IN      RRSIG   TLSA 15 3 3600 20230816055855 20210808025855 27214 letsdane. [omitted]

If any of these records is updated at a later point that's before the RRSIG expiration, the older records can still be used for replay attacks because they have valid signatures.

Some solutions:

1. Give the nameserver the DNSSEC keys and let it take care of signing (you can rotate when changing providers) but it wouldn't be zero trust.
2. Rotate the DS record in the root zone whenever a record in the child zone is updated.
3. Optionally ask the user if they want to rotate when updating records. Replay risk isn't important for changing some record types like A/AAAA.

For 2,3 some considerations are needed with key rollover to avoid downtime see RFC6781 section 4

[pinheadmz]

Good ideas, thanks. Another consideration I'm having is using an account from BIP44 instead of a new purpose. The reason would be that it work wihtin our ledger app! I've contacted the Ledger developers to see if they have a DNSSEC app, it would be a cool app for the device especially (obviously) for HNS users. But it wouldn't HAVE to be locked into Handshake. They already have apps for PGP and SSH, I think it would be cool if we could get a hardware-wallet standard for DNSSEC outside of HNS, that we could then use in our community.

Alternatively, we can look at it differently: that maybe its "OK" for Bob Wallet to manage DNSSEC keys on a "hot" machine, and users could keep their HNS and names on the ledger but use a second wallet in Bob for DNSSEC and zone management.... that will probably end up being messy though.

[brandondees]

My thinking is that "hot" keys are fine and normal to use for DNSSEC operations as long as they can be short lived / auto-rotated, and as long as the breach of a given DNSSEC key doesn't compromise the rest of the wallet. It seems to be common practice to rotate DNSSEC keys on a 90 day schedule automatically, to mitigate the risk of short keys being cracked, or to limit impact in the event of a key compromise.

I like the idea of bob wallet providing easy GUI management of DNSSEC but I want to be sure that any major security/privacy caveats are spelled out clearly to the user before they go shooting themselves, since most users won't understand the cryptographic mechanisms and their tradeoffs at either the cryptocurrency level or at the dnssec level, they'll expect to be taken care of properly by default, and might still go ahead and bypass the GUI for some things that the UI doesn't support.

[brandondees]

you have to increase the signature lifetime otherwise it wouldn't be practical

@buffrr care to clarify this a bit more? how long are we considering practical vs not, or what would you suggest as a default? with good tools for supporting the management operations from an offline storage device, wouldn't some of the practical problems be manageable? we might want to try to cater to multiple levels of paranoia. I imagine for most needs the maintenance chore is not that laborsome to do even using something like a ledger, but the significant tradeoff involved is that the offline storage hardware needs to be "on hand" on the regular schedule as opposed to kept in some more secure cold storage location all the time. I think it'd be nice to have some kind of strategy available for the folks who really do want to have the maximum level of cold storage security, but to assume that the typical user is not taking those extreme measures and would rather have a balance of convenience and still-good "online" protection which they can adjust to their comfort.

[Falci]

It seems to be common practice to rotate DNSSEC keys on a 90 day schedule

Is it?

[brandondees]

that's the icann root, i'm talking about individually managed domains