How do we set encrypted / authenticated channels up ? [was: Do we really need encrypted / authenticated channels] about practical-revault

[JSwambo]

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]

The .onion address appears to be random

They better be!

this protection is brittle in that it relies on a secret that may not be well guarded

Definitely.

Privacy of operations is a good point as well (but signatures do not reveal the actual transaction).

Noise_KX is the 'middle ground', where the initiator is assumed to be pre-authenticated by the responder.

It's what we want to complement the authentication of the server by the onion pubkey.

Provided that clients can communicate among each other securely then this exchange can occur after the ceremony.

That's not very practical though: they don't have a direct communication channel between each other.

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)?

Depends, which server ?

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.

It's not strictly necessary and given for free by the underlying layer (onion pubkeys).

[JSwambo]

Privacy of operations is a good point as well (but signatures do not reveal the actual transaction).

The sig message to the co-signing server does reveal the PSBT.

It's what we want to complement the authentication of the server by the onion pubkey.

Yes, although I would argue that the authentication from noise is primary (as things currently stand). If we decide to use Tor authentication (should we?), then I suppose they are equal and complimentary.

That's not very practical though: they don't have a direct communication channel between each other.

It's not direct, it can be routed through the Sync Server. In this case using noise_KK is feasible (the keys can be exchanged during the ceremony), and probably necessary to avoid introducing a weak link at the Sync Server.

Depends, which server ?

Each watchtower operator will have to initialize their watchtower with their static pubkey for communication. Each co-signing server operator will have to initialize them with the managers' static pubkeys. How will these be transported? What risk do active attackers pose here? The communication private keys can be kept on an off-line device, but the public keys might be susceptible to being changed with a malicious one.

[darosior]

The sig message to the co-signing server does reveal the PSBT.

Yeah, you would have to break Tor though, but Tor assumptions are definitely not part of our security model.

then I suppose they are equal and complimentary

There are different things. By default, communications through Tor are encrypted and authenticated (receiver-side). We could have authenticated hidden service in addition but i prefer to instead roll up our own noise channels as Tor's is a practically nice thing to have but not something that should be part of our theoretical security model.

It's not direct, it can be routed through the Sync Server. In this case using noise_KK is feasible (the keys can be exchanged during the ceremony), and probably necessary to avoid introducing a weak link at the Sync Server.

I really don't like the idea of supporting that software wise.. I need to think more about it.

[JSwambo]

Tor's is a practically nice thing to have but not something that should be part of our theoretical security model.

Agreed!

I should also add to the conversation that connections will be dropped from time to time. If the noise state is maintained then a handshake will not necessarily need to be repeated, but a listening server can only recognize a specific client by their IP address or by attempting to decrypt any received message according to their current set of noise states. If for some reason a client's IP address changes after the connection is dropped then the server will have to attempt to decrypt according to their known set of clients' noise states until one yields a sensible message. This isn't ideal because we want to avoid costly computations for each new connection (and avoid DoS attacks) by silently rejecting unauthenticated clients. How big is the risk of changing IP addresses? Is it better to re-establish all dropped connections with a new handshake than to attempt to continue communication using the latest noise state? Is this a good motivation for using noise_KK or noise_KX, and re-establishing dropped connections with long-term static public keys?

[darosior]

How big is the risk of changing IP addresses?

We don't rely on IP address, and actually are not using them: watchtower are connecting through Tor to the sync server.

Is this a good motivation for using noise_KK or noise_KX, and re-establishing dropped connections with long-term static public keys?

It is for KK at least for revautld <--> WT.

[darosior]

This has been discussed and will be fixed by @JSwambo as part of an upcoming PR.