privval: authenticate and persist keys for tcp conns

[ebuchman]

The TCPVal uses a SecretConnection over TCP, but does not currently authenticate the connection against a known node ID.

For the TCPVal, we need to:

• persist (and encrypt) the TCPVal.secretConnKey

For the RemoteSigner (and any KMS implementation), we need to:

• format address to dial as ID@host:port or ID@tcp://host:port
• authenticate the dialed ID against the remote ID from the SecretConnection

Replaces part of #2549

[tarcieri]

I implemented the KMS side of peer verification for the priv_validator_laddr listener here:

tendermint/tmkms#219

It works! But we're running into the keys not being persistent.

I'm tracking that on the KMS side in this issue: tendermint/tmkms#111

[tarcieri]

@ebuchman I think you can check off the first "For the RemoteSigner (and any KMS implementation)" box as of tendermint/tmkms#219 (it uses tcp://ID@host:port with a presently optional ID@, which is what gaiad's config.toml uses).

Regarding persisting the key on the Tendermint side, I'd suggest just using the existing node key. This is how I've typically seen mutually authenticated TLS deployed (i.e. there is a single key identifying TLS principals for all client and server connections), and I don't see any potential threats using an additional key would mitigate.

[tac0turtle]

With the migration to gRPC I don't believe this is relevant anymore?

[tarcieri]

@marbar3778 I imagine we'll migrate to X.509 certificates? So long as the validator has a stable key / certificate for the KMS to verify, this won't be an issue.

[tac0turtle]

x509 are the default used certificates with gRPC. I don't think there is a way to use anything else but haven't looked into it.

In another issue, Hendrik mentioned that having TLS is a plus but if we document well that the port should only be exposed to your KMS it should be fine as well. I will document how to do both with TLS and without.

will close this issue

[tarcieri]

I would strongly suggest always encrypting the connection between the validator and the KMS.

[tac0turtle]

This will be the recommendation made in the docs

[tarcieri]

gRPC is HTTP/2-based, and many HTTP/2 implementations are always-encrypted, so I'm not sure it will even be possible to support a plaintext option