HIP-0002

[publiusfederalist]

The known wallet file, .wallet, is not actually fully secured by the chain of trust in this proposal. The certificate itself is but not the contents of the web server which are served out of band.

There are better options:

Coupling the name and the receive wallet

1. The name itself is associated with a UTXO, and therefore, a wallet already.

Decoupling the name and the receive wallet

1. A receive address can be stored on chain as a TXT record.
2. A receive address can be served as TXT record by a DNSSEC secured authoritative zone.
3. Use suggested HTTPS method, but with a signed message containing the receive address.

There are likely other options. By including the language in Decoupling#3 or by using one of the other options, a sender can rest assured they are sending to an address verified by the chain of trust as opposed to a potentially hacked web server that continues to maintain the right cert.

[pinheadmz]

HIP2 was written with the following design considerations:

1. Static addresses / address reuse is bad practice
2. Updating data on chain is slow, cumbersome and expensive
3. App developers are more familiar with HTTPS requests than DNS requests (and even less familiar with querying blockchain data directly)

I'll add a few more notes to this:
4. The address that owns a name may not be the name owner's desired receive address. For example it could be a cold / hardware wallet, a multisig address with complicated spending policy, or even a custodial address.
5. If a NS record exists for a TLD in the root zone the root name server will not return any TXT record because the zone has been delegated.

You are right that DNS records can at least be signed offline, meaning a compromised name server is less of a problem than a compromised web server in the HIP2 model.

I kinda like your idea of signing the wallet addresses with some other key to protect against web server attacks but that might compromise our preference of dynamic invoicing over static address reuse.

[publiusfederalist]

Dynamic invoicing can still occur with signed addresses by simply signing n addresses (thus, n signatures) and storing them ahead of time, and then dynamically releasing 1 at a time until y times where n - y is lower than a minimum threshold set by the user based on address uses.

• For example, if I believe I perform 1000 unique HNS transactions in a month, then I might want to have 1200 addresses pre-signed and stored on the web server.
• The .wallet will take care to issue 1 per unique user and track which were issued and, potentially, to who in many cases (session id, token, fingerprint, etc.).
• Upon using or issuing 1000 addresses and leaving 200 remaining, I may have a system to notify me to generate additional HNS addresses to store in a file inaccessible by the public, all pre-signed.

The risk of being hacked or brute forced and losing pre-signed wallet addresses is that you spent a few minutes generating addresses at worst and might receive more coins at best.

[pinheadmz]

I like where this is headed. What key would sign all the addresses? Would it be the ZSK for the domain or something else in a TXT?

Also want to be clear about the attack vector here. It's similar to Coinbase getting hacked and all their deposit addresses getting swapped for an attackers wallet. But since HNS assumes all users are running their own name and web servers it seems prudent to add one extra check for systems with less OPSEC than Coinbase.

[pinheadmz]

ps are you able to join the developer telegram? https://t.me/hns_tech

Your federalist project is super awesome! Can't wait to try it out.

[publiusfederalist]

Absolutely agree. The original attack vector is as you describe.

I think it might be worth giving the site/domain owner options as different stakeholders in the ownership and/or operation of the domain may be holding different keys which would give flexibility to not having to share. In addition to the domain and ZSK, there could be an additional generated keypair just for this use case, controlled by a finance administrator with the signing pubkey attested elsewhere besides the web server (on chain, in signed zone, etc.).

I guess it really depends how complex we want to get with default and or proposed standard use protocols while maintaining the flexibility of being adopted by any organization or user with any level of security and key management systems in place.

[publiusfederalist]

Would you have a developer mailing list?

[brandondees]

Yeah I think the pinned signing pubkey concept is a good enhancement. It'd be nice to keep it from becoming something too cumbersome for the casual website administrator to adopt, and keep it flexible enough to allow for the wide range of different owner / org / wallet / web configurations that are likely to occur. The client side integration should be kept as straightforward as it can in the process to avoid hampering useful adoption, but wallets and webservers are a few:many relationship at least.

Is there a process in place already for deprecating an improvement proposal in favor of a better replacement proposal?

[brandondees]

I think that currently the telegram dev chat and github itself are standing in for a mailing list so far.

[publiusfederalist]

I think discussion on the github issues and a PR might work for the time being, but I defer to the project maintainers for guidance.