JSwambo
commented
4 years ago The obvious major benefit to running the servers as onion/ hidden services is that their IP address remains confidential. This mitigates the risks of adversaries learning identity or location information and potentially to malware injection or other attacks.
The .onion address appears to be random and should be difficult for an external adversary to guess, which somewhat mitigates DoS attacks, but this protection is brittle in that it relies on a secret that may not be well guarded (if the onion address is stored on laptop/ PCs running revaultd). An additional way to mitigate DoS attacks (from external and insider adversaries) is to require client authentication to the server. This provides accountability of communication events and enables the server to restrict access to its functionality through anti-DoS logic.
Now, from the client's point of view the information they intend to send to a server should remain confidential (not because sending signatures in clear-text enables a theft, but because otherwise operational privacy can be broken if intercepted, which could for example enable front-running a trade).
A noise channel (specifically noise_KK, noise_KX, and noise_XX) provides authentication and confidentiality after the initial handshake, but the different variants have different underlying assumptions for the handshake messages themselves. Noise_XX is a reasonable choice in a p2p network where neither party knows the other in advance, but since the initiator's first message doesn't benefit from sender authentication it could have been sent by an active attacker. Noise_KK provides the strongest mutual authentication during the handshake, assuming the out-of-band exchange of static keys is not compromised. Noise_KX is the 'middle ground', where the initiator is assumed to be pre-authenticated by the responder.
The requirement for practical-revault is to minimize the procedural overhead of the initialization and ceremony, while retaining a high-level of authentication and confidentiality. So I propose that Noise_KX be used for client-server communication channels. This requires participants to pass 'out-of-band' all relevant static communication public keys (including in some cases those of other participants, gathered during the ceremony) to the servers they manage, but does not require the server to be initialized before the ceremony. One complication for this is that the (sync and co-signing) servers' onion address information must be exchanged between participants. Provided that clients can communicate among each other securely then this exchange can occur after the ceremony. That way there is no need for participants to perform any initialization before the ceremony (besides device procurement). This secure communication between participants can be mediated by the sync server to avoid the need for direct connections, but will require participants to exchange long-term static public keys for communication during the ceremony.
The out-of-band exchange of static keys from participants and the servers they manage must be done securely -> this raises the question of how to transport this information (physically and digitally)?
Another question worth considering; is it necessary for servers to authenticate themselves to clients? This authentication will come 'for free' if using one of the noise variants mentioned. Though I'm not sure it is strictly necessary.
darosior
All 3 servers (cosigner, wt, sync) are ran behind an onion service.
We could assume the tor encryption and the auth as in "knowing the actual onion". If we don't want that then we need noiseKX or even noiseKK communication channels between each authorized-to-connect-here entity and the server.
Do we need it ? What would be the consequences on the ceremony / setup ?