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?
Idea: preventing short-term effects of name theft using lock
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Idea: preventing short-term effects of name theft using
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.
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.
Re: Idea: preventing short-term effects of name theft using
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.
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.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Idea: preventing short-term effects of name theft using
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.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.
Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
Re: Idea: preventing short-term effects of name theft using
This is only by design of how the client currently handles updates by default. It can easily be changed, e.g. via an option.biolizard89 wrote:You do realize that names by design move every time they're updated or renewed, right?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.
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.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.
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?Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Idea: preventing short-term effects of name theft using
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:This is only by design of how the client currently handles updates by default. It can easily be changed, e.g. via an option.biolizard89 wrote:You do realize that names by design move every time they're updated or renewed, right?
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: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.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.
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:phelix wrote: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?Do you actually have criticisms of the proposal? "Too complicated" by itself is not really a criticism.
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
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.