This is something that @david415 questioned a while ago: how to block
a peer you previously had a conversation with?
I believe that unMessage is going to be used mostly for long-term
conversations (that is also one of the reasons why the Double Ratchet
Algorithm was made) so we will inevitable need a way to delete
conversations for good and block peers.
Although the unMessage user can delete a conversation and packets sent
from that blocked peer will be seen as malformed and then ignored,
they can continue connecting and sending packets because the Onion
Service address is known. As we currently use a single OS for each
peer, we cannot change that address because then we have to notify all
other peers that are not blocked and that is a synchronous process.
@rxcomm and I discussed it and here is the best idea we had so far:
Create one OS to be used exclusively for requests
Create a separate OS for each conversation that is established
To delete and block the peer, stop using the conversation OS - the
blocked peer only knew that OS and the requests one
As the blocked peer knew the requests OS, change it - the other
peers will continue connecting to the respective conversation OSes
Other things we should think about:
Discuss if the peers that are not blocked may need to use the
requests OS - if so, they can be informed of the new one the next
time the reconnect through their conversation OSes
Use authentication cookies to make the conversation OSes stealth
Discuss how useful ratcheting the authentication cookie may be and
how to do it
Only accept request packets by the requests OS, and regular packets
by the conversation OS
The solution partially helps solving the following attack:
- unMessage maps an Onion Service to a local server that accepts
connections and `receives netstrings`_ to be parsed as unMessage
packets. This behavior allows an adversary who has knowledge of a
peer's Onion Service address to perform the attack mentioned in
item `4`, by either making the Onion Service inaccessible in the
network or overloading the unMessage instance.
If a conversation OS is attacked, we can assume the other peer is the
attacker or was compromised and then delete it. However, due to the
requests OS we would still need to keep the following assumption:
4. An adversary is unable to perform an attack by making multiple
connections or sending multiple requests to a peer whose unMessage
address has been acknowledged by them, making that peer
unavailable to others.
It is not clear yet how people will use unMessage: will they share
their identity key and request address only with people they know and
trust not to perform such an attack or will they print that to
business cards and post to their web pages?
It is possible that regular users may fit the former, but journalists
and services that can be contacted by anyone at any time may fit the
latter. Changing the requests OS helps mitigating such an attack, but
if the address has to be public (as in the second case), the users
must keep their contact information updated and determined adversaries
can just keep track of that and attack every new address. So we still
need to find a way to secure the requests OS. Some ideas:
Require proof-of-work (PoW) as part of the request
Always use an authentication cookie and inform it (somehow) when
someone wishes to send a request
It seems that 1) should be used for any kind of peer and 2) could be
supported if users do not even want to have their peers "pinged" by
unauthorized people.
This is something that @david415 questioned a while ago: how to block a peer you previously had a conversation with?
I believe that unMessage is going to be used mostly for long-term conversations (that is also one of the reasons why the Double Ratchet Algorithm was made) so we will inevitable need a way to delete conversations for good and block peers.
Although the unMessage user can delete a conversation and packets sent from that blocked peer will be seen as malformed and then ignored, they can continue connecting and sending packets because the Onion Service address is known. As we currently use a single OS for each peer, we cannot change that address because then we have to notify all other peers that are not blocked and that is a synchronous process.
@rxcomm and I discussed it and here is the best idea we had so far:
Create one OS to be used exclusively for requests
Create a separate OS for each conversation that is established
To delete and block the peer, stop using the conversation OS - the blocked peer only knew that OS and the requests one
As the blocked peer knew the requests OS, change it - the other peers will continue connecting to the respective conversation OSes
Other things we should think about:
Discuss if the peers that are not blocked may need to use the requests OS - if so, they can be informed of the new one the next time the reconnect through their conversation OSes
Use authentication cookies to make the conversation OSes stealth
Discuss how useful ratcheting the authentication cookie may be and how to do it
Only accept request packets by the requests OS, and regular packets by the conversation OS
The solution partially helps solving the following attack:
If a conversation OS is attacked, we can assume the other peer is the attacker or was compromised and then delete it. However, due to the requests OS we would still need to keep the following assumption:
It is not clear yet how people will use unMessage: will they share their identity key and request address only with people they know and trust not to perform such an attack or will they print that to business cards and post to their web pages?
It is possible that regular users may fit the former, but journalists and services that can be contacted by anyone at any time may fit the latter. Changing the requests OS helps mitigating such an attack, but if the address has to be public (as in the second case), the users must keep their contact information updated and determined adversaries can just keep track of that and attack every new address. So we still need to find a way to secure the requests OS. Some ideas:
Require proof-of-work (PoW) as part of the request
Always use an authentication cookie and inform it (somehow) when someone wishes to send a request
It seems that 1) should be used for any kind of peer and 2) could be supported if users do not even want to have their peers "pinged" by unauthorized people.