Revocation

[phelix]

Assume you have a domain with a lot of users. Your privkey gets stolen, name transfered. Or you simply forget to update and it expires. Bam, you are in trouble.

How to prevent it from happening? Double layered entries with import?

How to make it less bad if it still happens?


(From discussion with Levino from Bitcointalk who will speak for Namecoin on a panel discussion on 30C3 congress.)

[biolizard89]

Assume you have a domain with a lot of users. Your privkey gets stolen, name transfered. Or you simply forget to update and it expires. Bam, you are in trouble.

How to prevent it from happening? Double layered entries with import?

How to make it less bad if it still happens?


(From discussion with Levino from Bitcointalk who will speak for Namecoin on a panel discussion on 30C3 congress.)

The import field is the correct way to do this. Keep the d/ name offline, and use a dd/ name for IP / other config updates. As far as I can tell, it should be possible to generate a bunch of renew transactions at once, and keep them on the online computer so that you don't have to worry about the d/ name expiring. E.g. you could generate name renew tx's for 10 years, and your online client could be configured to broadcast them 1-by-1 every 28000 blocks or so. You could even use LockTime so that they can't be broadcast early, and then share the signed tx's with your friends so that if you go offline, they can renew it for you, without being able to hijack the domain. (I imagine some paid services might be setup to provide this.)

Obviously this scheme is dependent on (1) the import field being implemented in nmcontrol, and (2) some easy way of doing offline transactions with Namecoin (e.g. Armory support). But, Namecoin itself doesn't need any changes for this setup to work.

[Pagel1928]

If the private key to your domain/name is stolen, you are fucked.

One way to make this scenario not so bad, is to publish your identity in namecoin with a pgp public key, and tell the users of your website that you have done so.

If you have multiple administrators, they can also add their identity/public key into the namecoin blockchain.

When your domain is robbed, you can sign a message alerting the users about what occured. It is less likely all of the administrators identity namecoin keys are stolen.

Otherwise, don't fuck up!

[biolizard89]

If the private key to your domain/name is stolen, you are fucked.

One way to make this scenario not so bad, is to publish your identity in namecoin with a pgp public key, and tell the users of your website that you have done so.

If you have multiple administrators, they can also add their identity/public key into the namecoin blockchain.

When your domain is robbed, you can sign a message alerting the users about what occured. It is less likely all of the administrators identity namecoin keys are stolen.

Otherwise, don't fuck up!

Yes, if the key is stolen, you're toast, but there are ways to make this very unlikely, e.g. cold storage (as I mentioned above).

[Pagel1928]

Right, you can use all the same techniques to protect you key as you would your normal bitcoin wallet.

[biolizard89]

So, revisiting this issue. I was talking with one of the Tor guys and he brought up the issue of revocation as a potential obstacle to using Namecoin with Tor. (There were other obstacles brought up too, but those are already being fixed.)

Here's the concern. Let's say you're using cold storage and importation to keep your names safe. Now let's say a motivated attacker is able to access your cold-storage keys via a physical attack (breaks into your house; bribes the bank that owns your safe-deposit box; etc.). Or let's say your keys have been otherwise compromised (bad things happen sometimes). The attacker then transfers your name to his address. Congratulations, you're officially fucked.

How can this be defended against? Here's a proposal which Pitbull and I came up with on the IRC.

When you register a name, you specify a Namecoin address as the revocation address. This address should be stored in a separate wallet from the address which owns your name, and should be kept in cold storage (it's an address, not a name, so it will never expire). You also specify a revocation period for the name.

If the name is transferred to a new owner via name_update, it starts a timer equal in length to the revocation period. Until that window closes (as well as before the transfer), the revocation address can authorize the immediate transfer of the name to the revocation address. Once the revocation window closes, the transfer is considered final and cannot be revoked anymore.

The revocation period can be reduced or extended with the signature of the owner address. However, this action is delayed until the previous revocation period does not conflict. For example, if my name's revocation period is 3 weeks, I can reduce it to 1 week, but if the name is transferred 1 week after I change the period, the effective revocation window is 2 weeks (not 1 week). Changing the revocation period does not require the signature of the revocation address. Changing the revocation address is affected by the revocation period. For example, if I sell you my name and my revocation period is 1 week, you must wait 1 week before you change the revocation address.

In the extremely unfortunate and unlikely event that you believe someone has compromised both your name owner's keys and your revocation address's key, you may use your revocation address to nuke the name. By doing this, you cause 3 things to happen:

(1) If users ask namecoind for the name, it will say the name has been nuked for your protection. The value of the name will be inaccessible.
(2) The nuke operation is considered a renewal (i.e. the name cannot be re-registered for another 36000 blocks).
(3) Any transfers of the name occurring during the previous N blocks (where N is the revocation period) are immediately voided.

Furthermore, the revocation address can authorize a "lock" operation on the name. This permits the name's owner to renew the name, but not change its contents or transfer the name. The lock operation can include a lock period, during which "unlock" operations must wait before the name is unlocked. This allows critical names to be renewed indefinitely while keeping the keys which are necessary to modify or transfer the names in cold storage. If the cold storage key is accidentally destroyed, but the owner key is still available, the owner can unlock the name, but this must wait for the lock period (during which the revocation address can override the operation). During the lock period, the revocation address can authorize a temporary-nuke operation, which will cause the name to be inaccessible until the name has received an update (which will be after the lock period expires). (This means that if a TLS key is compromised, and the d/ name containing the fingerprint is locked, the d/ name can be temp-nuked, which will replace a hijacking attack with a much less severe DoS attack.)

As a parallel level of protection (defense in depth), it should be possible to transfer a name to a P2SH (multisig) address which acts as multifactor authentication. Both owner addresses and revocation addresses can be P2SH addresses.

What do people think of this proposal? (Big thanks to Pitbull for a productive back-and-forth conversation where we fleshed out these details.)

[virtual_master]

The solution with /dd and revocation are good ideas.
But let's see in detail:
- /dd is to hierarchical(by a non hierarchical organization would force a hierarchical solution) and only transfers the problem to another level but is not bad as starting idea
- the revocation is acting after the damage already happened but it is still better than nothing


As I see that so many people are interested on this issue, now I thought about it and I have a slightly different idea:
I took as starting point the PPC POS mining style, where for the mining you need another password than for a transaction for not to endanger your coins.
- we could implement to use another password to renew a name than to make a transaction from that address(name transaction also)
This password could be deterministic related to the transaction password(for. ex. a hash of it) than with the transaction password you always can create the name renew password.
If somebody steels the renew password which is in a hot wallet then he can only renew the name for the owner with it. But this solution is still hierarchical.
- Now let's improve it to be non-hierarchical if needed(but could be used hierarchical also).
a. To transfer the name would be required the renew password and the transaction password. This could be on different places by different persons by an organization.
b. To transfer a name would be required a set of password to be entered.(can be limited the number or not)
This set of passwords could be eventually in a (n from m passwords required, n<m) style.
From this set of transaction passwords the you can always create the name renew password.
This would create the most highest security and flexibility by an organization or company.

[biolizard89]

The solution with /dd and revocation are good ideas.
But let's see in detail:
- /dd is to hierarchical(by a non hierarchical organization would force a hierarchical solution) and only transfers the problem to another level but is not bad as starting idea
- the revocation is acting after the damage already happened but it is still better than nothing


As I see that so many people are interested on this issue, now I thought about it and I have a slightly different idea:
I took as starting point the PPC POS mining style, where for the mining you need another password than for a transaction for not to endanger your coins.
- we could implement to use another password to renew a name than to make a transaction from that address(name transaction also)
This password could be deterministic related to the transaction password(for. ex. a hash of it) than with the transaction password you always can create the name renew password.
If somebody steels the renew password which is in a hot wallet then he can only renew the name for the owner with it. But this solution is still hierarchical.
- Now let's improve it to be non-hierarchical if needed(but could be used hierarchical also).
a. To transfer the name would be required the renew password and the transaction password. This could be on different places by different persons by an organization.
b. To transfer a name would be required a set of password to be entered.(can be limited the number or not)
This set of passwords could be eventually in a (n from m passwords required, n<m) style.
From this set of transaction passwords the you can always create the name renew password.
This would create the most highest security and flexibility by an organization or company.

Hi virtual_master,

If I understand correctly, your proposal is to require a different key to transfer, modify, or renew a name. Is that correct? If so, I think that would definitely be useful, and could work in parallel to the dd/ solution and the revocation address solution (they're all solving different -- though related -- problems). The dd/ solution's main goal is to have different keys for modifying different parts of the same name; the revocation address solution's main goal is to provide a way to recover after an important key is stolen/lost; your solution's main goal is to have different keys for different operations on the same name -- all of these can work together. I'm not sure how easy having different keys for different name operations is; presumably it's doable with P2SH addresses (that's how multisig works). Any Bitcoin experts want to chime in here?

(By the way, I spent about 45 minutes rewriting my answer here about 4 times... I'm thinking out loud here. )

[virtual_master]

(By the way, I spent about 45 minutes rewriting my answer here about 4 times... I'm thinking out loud here. )

Thanks for the answer.

Hi virtual_master,

If I understand correctly, your proposal is to require a different key to transfer, modify, or renew a name. Is that correct? If so, I think that would definitely be useful, and could work in parallel to the dd/ solution and the revocation address solution (they're all solving different -- though related -- problems). The dd/ solution's main goal is to have different keys for modifying different parts of the same name;

This is correct. However I referred only to the name renewal and the name transfer. But surely the name modification should be also considered. You probably thought more about this so I let this part inclusive the dd/ issue on your appreciation.

the revocation address solution's main goal is to provide a way to recover after an important key is stolen/lost; your solution's main goal is to have different keys for different operations on the same name -- all of these can work together.

I make the revocation of id/ transfer parallel with the password hint on some websites.(even on banking sites) If you forgot your password then you should enter your mother name. But this doesn't improve security, only adds new attack possibilities as id/ is also not more secure then d/ and then could be attacked on multiple levels. It would also contradict to the cryptocurrencies principle of non reversible transactions. (should include name operations also) Solving the transfer with multisig keys would make secure enough.
If all keys are stolen what is the guaranty that it is not stolen the ID also ?

I'm not sure how easy having different keys for different name operations is; presumably it's doable with P2SH addresses (that's how multisig works). Any Bitcoin experts want to chime in here?

This is of course a good question. However in the Bitcoin/Namecoin protocol multisig transactions are implemented and theoretically this must be only implemented in the client so no hardfork is necessary. To separate the name renew (and eventually name change/even on different parts) with different validation key is a different issue and would require a different solution. We can think about.

[phelix]

Revocation via a special address imho interferes with how the system is supposed to work.

In any case revocation should only allow to set the value to "REVOKED" and nothing else.

What about this:
* Allow renewal with the same value by anybody (no idea how this could be implemented)
* Use multisig for security (I like this suggestion a lot)