⚗️ COMIT nodes need an identifying key

[LLFourn]

Decide how to handle COMIT node identification.
This MUST be compatible with noise, ie, if Alice already knows Bob's id, she needs to be certain she is connected to Bob when negotiating the noise connection.

Most likely public/private key pair, yet to be decided:

• what handshake protocol
• how to store locally
• how to backup (if needed)
• how to alias
• how to generate

Notes:
The current proposal is to use a public key which would also be used to set up transport encryption with the [noise protocol] (http://www.noiseprotocol.org/). This is precisely what The BOLT specification does. We would use it in the same way except not necessarily with the same parameters (hash function/curve).

This is needed so we can uniquely identify nodes. Right now nodes are identified with ip and port and there is no transport layer encryption/authentication. This also makes testing multiple nodes on the same machine difficult.

DoD:

• Proposal in comments
• Update Return id in GET peers http API #662

Child of #744

[thomaseizinger]

I'd say there is not really a way around having a key-pair for your COMIT node so that is sort of a given.

There is several questions to be answered/discussed:

• Users should be able to connect to another node and simply "trust"/"learn" their public key as part of the connection setup.
• Users should be able to specify an expected public key upfront and fail the connection setup if the other party doesn't identify with the expected public key.

For the 2nd case, the user's COMIT node needs to have list of socket addresses and public keys somewhere.

• This probably needs some sort of configuration file.
• The HTTP API needs to be able to accept different combinations of connection information:
  • public key + socket address pair (for connecting to unknown user with pubkey-verification)
  • socket address (for connecting to unknown user without verification or with public key stored in config file)
  • public key (for connecting to known user where the socket address is stored in the config file)

[LLFourn]

Whenever I someone shares a COMIT node id it should probably include an ID, IP and port. Can you think of use case for just sharing an IP/port?

Obviously you really have to not care at all who you are talking to if you just connect to an IP and port because it can be MITM attacked. It's also tricky to implement both types of handshakes in noise.

[LLFourn]

Theres's two main choices:

1. Noise_XK_25519_ChaChaPoly_BLAKE2b
   • It's part of the noise specification
   • It's more efficient
2. Noise_XK_secp256k1_ChaChaPoly_SHA256
   • PR is here but not merged try to add secp256k1_support mcginty/snow#38 (it LGTM)
   • We could use the same public key on the lightning network if we were to implement BOLT.

[LLFourn]

Proposal:

• Use noise Noise_XK_25519_ChaChaPoly_BLAKE2b or Noise_XK_secp256k1_ChaChaPoly_SHA256.
• Your node's private key and therefore public key would be derived from the 32 byte COMIT seed.
• Storage and how you generate is then however you store the seed

Note if we go with Noise_XK_25519_ChaChaPoly_BLAKE2b I would probably use BLAKE2b for all secret secret derivation. We need to put more thought into secret derivation

I think "aliasing" is a feature we should design until we have a motivation for it at the application level. At this stage I can see that an application might like to tag peers or add metadata to them. But I think it makes most sense to do this on the application level.

[LLFourn]

Sent a meeting invite to discuss this above

[D4nte]

"Storage and how you generate is then however you store the seed".
Do you mean that the seed should be entered somewhere every time you start up the node?
I'd expect to have a key file present beside the configuration to allow re-use of same id.

[LLFourn]

@D4nte No. I mean that the key is simply derived from the seed. Seed storage/security improvements are outside the scope of this proposal.

[D4nte]

@LLFourn please see body ticket "how to store locally". Please include a proposal regarding this matter.

[LLFourn]

That I'm closing this for now with the bias towards Noise_XK_25519_ChaChaPoly_BLAKE2b but the change in direction discussed Friday may further influence this decision.

Note: Further discussion about key derivation can go here #672