(RFC) Alert devices trying to communicate with a compromised tox id.

[abueide]

Proposal to #1343

Description

There should be a flag in a profile DHT which is initially false. Any user with the private key corresponding with the tox id can cryptographically sign this variable and set it to true, but all nodes will deny any requests, signed or not to set the flag to false. This would essentially permanently mark the id as compromised so the attacker won't be able to change the value to false. Every client should alert any user trying to interact with the tox id that it is compromised and all communications with it should be considered unencrypted.

Why do this instead of just alerting all friends?
Because this will also alert anyone trying to add the tox id that it is compromised, and also to any friends that are offline.

Use case: A vendor is selling items over tox. Their private key is compromised. They switch to a new tox id, but they want to make sure any one who tries to add him or talk to him knows that it is compromised and they shouldn't conduct any trade and assume communications with the tox id are unencrypted.

Topics for Discussion

Verify the node the flag is received from

How do we make sure a client is receiving correct information about if a tox id is compromised? Can an attacker flood the networks with nodes that are distributing that the compromised flag is set to false? Does DHT just rely on the fact that if there was a node distributing bad information, it wouldn't matter because it can be verified that a device is the tox id they say they are by using their tox id's private key?

Method to set flag to true even if private key is lost

1. Just back up your tox profile key
2. Generate a tox id public/private key pair via a bunch of randomly generated words that can be written down on paper, like with bitcoin and suggest the user keep it some where safe in more than one location.

[GrayHatter]

What nodes would be required to store this data?

How long would they be required to store it?

How many ToxIDs would each node be expected store?

How do we make sure a client is receiving correct information about if a tox id is compromised?

What?

Can an attacker flood the networks with nodes that are distributing that the compromised flag is set to false?

Yes, how would you prevent that?

Does DHT just rely on the fact that if there was a node distributing bad information, it wouldn't matter because it can be verified that a device is the tox id they say they are by using their tox id's private key?

What?

[abueide]

@GrayHatter Do dht nodes not already store tox id's along with ip? What1 Rephrase: "Is there a way to make sure a node is providing the correct information and is in sync with the rest of the network?" - maybe by checking with multiple nodes? I'm not sure how to protect against node flood, but having this would be better than nothing. What2 rephrasing "Does current dht not care if nodes are providing wrong data, because of public tox id authentication?"

[optimumtact]

there is no current protection against a bad node flood iirc

[GrayHatter]

@GrayHatter Do dht nodes not already store tox id's along with ip?

they do... but what does that matter?

What1 Rephrase: "Is there a way to make sure a node is providing the correct information and is in sync with the rest of the network?" - maybe by checking with multiple nodes?

No, there's no way to prove a node is lying, expect that it wouldn't give you anything at this point.

I'm not sure how to protect against node flood, but having this would be better than nothing.

Unless I lie and make all of your friends think you've lost your keys

What2 rephrasing "Does current dht not care if nodes are providing wrong data, because of public tox id authentication?"

If I understand what you're saying. Yes, if a node lies, it doesn't matter much

there is no current protection against a bad node flood iirc

You can't pretend to be a PubKey if you don't have the SecKey

[abueide]

they do... but what does that matter?

They store the flag for as long as they would store the dht entry for that tox id

Unless I lie and make all of your friends think you've lost your keys

It is cryptographically signed by the private key of the tox id. So you can't lie in the same way you can't pretend to be a tox id, unless you have the private key of the tox id in which case the flag should be triggered anyway.

Every client can check if the flag came from the tox id's private key without trusting anyone.

[aaannndddyyy]

@abueide they don't store it longterm, so if the real legit user is offline, the impostor can come online and all the flags are again/still set to false.
That's why I still consider a revok cert to be the best choice, just like they exist for well-known pgp

[abueide]

@aaannndddyyy Ah okay that makes sense. I was mistaken on how DHT works. How does certificate revokation work?

[GrayHatter]

You register with a remote host, and then all of your friends have to download the latest list of "revoked keys" then compare your key to that list. If it's on that list, you know you can't trust the key.

[SkyzohKey]

You register with a remote host

Centralization eh. We could also have something like built-in Tox torrent to share files that would be seeded by random peers on the network, ensuring the network neutrality and an enhanced security.

[aaannndddyyy]

Well, registering with a remote host is just an add on.
Basically, you create a standardize message instructing the receiver to discard the tox id it was signed with.
This message is sent to all your contacts. And of course signed with your key.
You can create it immediately after creating your id, or any later time.

A client could prompt the user for confirmation and a password in order to "release" the revocation.

[GrayHatter]

You can't sign messages with the default tox implementation.

A client could prompt the user for confirmation and a password in order to "release" the revocation.

How would that work?

[aaannndddyyy]

I know.
But nacl and libsodium can do, using the tix id's pk. And those are already dependencies.

Well, how a client opens a password dialog and will only send out the revokation, should be trivial.

[GrayHatter]

Well, how a client opens a password dialog and will only send out the revokation, should be trivial.

I know how to get a password prompt, I mean how would the entire workflow be inside toxcore.

From creation of account to sending of the revocation?

[aaannndddyyy]

1. account creation like now, plus ask the user client-side if he wants to generate a revocation certificate. If user says yes, this certificate is generated and saved

2. revocation certificate can be created also at any later time, but during "account creation" should be that option so that the user will be aware of this possibility.

3. user uses tox

4. someone somehow got access to his device and the password was cracked

5. user noticed it (unfortunately this is required in any revocation scenario)

6. user still has access to his tox or a backup thereof

7. he connects, and pressed the " this I'd is compromised " button

8. in order to prevent abusive friends whom the user gave access to his device for 5 minutes to use this button to maliciously , I password has to be entered

9. if PW was correct, the revocation is loaded from the specified path and sent as a special kind of message, that the user cannot do without entering that password. This is to prevent malicious friend Malcolm whom the user gave access to his to x in order to say hi to his grandma from finding the cert and sending it as a normal file transfer.

Contacts receiving it alarm their user and urge them to consider the connection to be insecure.
No automatic deletion, as it still might be the only way of contacting a certain contact.

In this setup no signing is necessary, as messages are all authenticated.

If you want also redistribute those certs - be it on a central server or via friends of friends, you'd need signing, which can be done with your crypto lib

That being said, I still think the best would be an authentication method built-in similar or identical to socialist millionaires or zrtp's comparing mechanism. Because that is resilient and considers the underlying transport just as a transport.
This would also help with the point raised above that in a revokation-based approach, you need to be aware of the fact that your key got compromised.
Advantage of revocation with redistribution is however, that it allows for new users that want to connect with someone they don't know personally, that they can find out about compromise.
In purely private setting, I don't see an advantage of revocation over a periodical re-authentication procedure.