Idea: preventing short-term effects of name theft using lock

Post Reply
biolizard89
Posts: 1990
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Idea: preventing short-term effects of name theft using lock

Post by biolizard89 » Tue Mar 03, 2015 7:33 pm

So I was thinking about dealing with stolen keys, and I have a rough idea.

Two new features are introduced:

1. Name operations are modified to include a "revocation period", defaulting to 0 blocks. After a name is transferred to a new owner, the previous owner can, during the revocation period, issue a "nuke name" command, which will cause the following 3 things:

a. All currency outputs tainted by the transfer operation immediately become permanently unspendable.
b. The name becomes unresolvable and unspendable, and is replaced by an error message that the name has been nuked by its owner to mitigate a key compromise.
c. The name cannot be registered again for 36 kiloblocks.

2. NMControl is modified to support a delay on introducing new TLS fingerprints. A reasonable number might be a week, depending on the circumstances. If a fingerprint is added to a record, it will not be considered valid until the delay has elapsed. Removing existing fingerprints takes effect immediately.

With these changes, let's assume that an attacker has compromised the private keys of a name which has authority over TLS keys. We also assume that the rightful owner's copy of the keys has not been destroyed. If the attacker tries to change the fingerprint to impersonate the domain, the new fingerprint will not become active immediately. During this window, the name owner will presumably notice that the name has been hijacked, and can issue a nuke command. The result is that the compromised name is *never* impersonatable, even during the short window before the name is nuked.

Is this potentially useful?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 1990
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Idea: preventing short-term effects of name theft using

Post by biolizard89 » Fri May 22, 2015 3:43 am

Suggested edit to the above: the NMControl TLS delay is always defined to be equal to the revocation period. That makes more sense than what I described above. Not sure why I didn't think of that in March.

Can we please get some feedback on this? One notable (very very cool) benefit of this is that you can give control of your dd/ names (including TLS config and other sensitive things) to an untrusted third party (say a web wallet) and as long as you check for mischief at least once per revocation period, they are unable to MITM you, even temporarily.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: Idea: preventing short-term effects of name theft using

Post by phelix » Fri May 22, 2015 8:21 am

Sounds too complicated to me.

What about this:

1.) The value contains a signer field as previously discussed.
2.) If a name moves it is considered compromised.
3.) Putting a signature from the original signer into the value activates it again.

Potential problem: The current signer needs to be stored together with the UTXO set.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1990
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Idea: preventing short-term effects of name theft using

Post by biolizard89 » Fri May 22, 2015 11:17 am

phelix wrote:Sounds too complicated to me.

What about this:

1.) The value contains a signer field as previously discussed.
2.) If a name moves it is considered compromised.
3.) Putting a signature from the original signer into the value activates it again.

Potential problem: The current signer needs to be stored together with the UTXO set.
You do realize that names by design move every time they're updated or renewed, right? Besides that, your proposal doesn't even try to solve the problem I'm addressing, which is theft of the keys that control the name. All your proposal does is redefine which keys control the name, and those keys can still be stolen -- which is exactly the same threat model as what import already addresses.

Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: Idea: preventing short-term effects of name theft using

Post by phelix » Fri May 22, 2015 2:44 pm

biolizard89 wrote:
phelix wrote:Sounds too complicated to me.

What about this:

1.) The value contains a signer field as previously discussed.
2.) If a name moves it is considered compromised.
3.) Putting a signature from the original signer into the value activates it again.

Potential problem: The current signer needs to be stored together with the UTXO set.
You do realize that names by design move every time they're updated or renewed, right?
This is only by design of how the client currently handles updates by default. It can easily be changed, e.g. via an option.
Besides that, your proposal doesn't even try to solve the problem I'm addressing, which is theft of the keys that control the name. All your proposal does is redefine which keys control the name, and those keys can still be stolen -- which is exactly the same threat model as what import already addresses.
I think it achieves something similar to your proposal. Key stolen, no harm done. Import does not do that for the master key. The difference is that two keys need to be stolen so you could argue that multisig 2 out of 2 for the name was similar.
Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
Sorry, I did not mean to be rude. The way I understand your proposal it would need a significant protocol change and operations in the client dependent on "other" transactions. Maybe something similar could also be done without a protocol change?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1990
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Idea: preventing short-term effects of name theft using

Post by biolizard89 » Fri May 22, 2015 11:22 pm

phelix wrote:
biolizard89 wrote:You do realize that names by design move every time they're updated or renewed, right?
This is only by design of how the client currently handles updates by default. It can easily be changed, e.g. via an option.
Bitcoin doesn't reuse addresses for a reason. Among others, Bitcoin becomes significantly weaker to quantum attacks when addresses are reused. (The anonymity issues with address reuse are less of a problem for Namecoin, because names are pseudonyms inherently.)
phelix wrote:
Besides that, your proposal doesn't even try to solve the problem I'm addressing, which is theft of the keys that control the name. All your proposal does is redefine which keys control the name, and those keys can still be stolen -- which is exactly the same threat model as what import already addresses.
I think it achieves something similar to your proposal. Key stolen, no harm done. Import does not do that for the master key. The difference is that two keys need to be stolen so you could argue that multisig 2 out of 2 for the name was similar.
The specific goal of my proposal is that for the entire set of keys that have influence of a name, theft of that set of keys does not allow the name to be impersonated. Neither multisig, nor import, nor your suggestion give that capability.
phelix wrote:
Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
Sorry, I did not mean to be rude. The way I understand your proposal it would need a significant protocol change and operations in the client dependent on "other" transactions. Maybe something similar could also be done without a protocol change?
No worries. :) It does require a change to block validation, as far as I can tell (including some tweaks to the script opcodes), but Ryan's delegated renewal also does this, so I don't think the fact that it changes script opcodes means we shouldn't do it. It just means that we should do it carefully. FWIW, I think there could be ways to implement this using minor script changes. Here's a rough pseudocode of how the script would look:

Revocable output:

Code: Select all

IF block height < revocation height
    IF spending scriptSig == current owner
        IF spending scriptPubKey == name script with permissions of OP_RETURN
            OP_TRUE
    ELSE IF spending scriptPubKey begins with the script fragment I'm listing in this code block:
        (do standard name script verification)
    ELSE
        OP_RETURN
(Yes, that script is poorly written, just consider the logic rather than the form.)

Bitcoin is (as far as I know) planning to introduce an opcode that checks block height. (I'm not sure if it's usable verbatim for this.) The main trick is being able to place restrictions on a scriptPubKey of the spending transaction, which happens to be exactly what Ryan's delegated renewal does. Things get slightly more complex when you have more than one revocation key+period in place at once, but the logic is the same.

Now -- all that said. There is a way to do *part* of this proposal, strictly for dd/ names, purely on the NMControl level. You can have NMControl query the blockchain history of a name, going back some number of blocks (let's say a month), and look for a "lock key height" field in the history. You can then ignore TLS keys until the height has passed. If a dd/ name is compromised (let's say it's in a web wallet and the wallet operator turns evil), the d/ name owner would have to take the d/ name out of cold storage to sign a transaction revoking the delegation to the dd/ name. This doesn't protect d/ names from key theft, but is substantially simpler (and still makes web wallets safe). Pruned nodes wouldn't be able to do this.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply