eliminating the need for certificates with the grpc / automating validation of certificates using a node's peer to peer pubkey

[AndySchroder]

lnd creates a certificate for the grpc. We also have a node pubkey that is used for securing peer to peer transport. At a high level, this seems a bit redundant to me to have two types of public keys for one node.

There are a few things that can be done to get the grpc client to work.

1. With an unsigned certificate, we can copy over the public certificate from the lnd node to the client and the client can validate that way. This method I don't think works if using macaroons for things like LSATS and subscription type services. Also, clients must be updated annually because the self signed certificate is only good for one year.
2. We can get a certificate signed by a CA. This is problematic because it requires the PKI, which requires us to trust every issuer that is trusted by the OS. This has never been a good design in my opinion, but it was 'the best' that could be done before a blockchain was invented. Lightning terminal has a method to use Let's Encrypt (https://github.com/lightninglabs/lightning-terminal/blob/master/doc/letsencrypt.md) to generate certificates automatically and get them automatically signed by Let's Encrypt (supported by most operating systems, browsers, etc.). This may or may not be in lnd, I don't know. However, as mentioned above, this has the problem of needing to trust every issuer, and, I believe that lightning-terminal uses the HTTP-01 challenge, which isn't really secure (see https://serverfault.com/questions/1031317/how-can-lets-encrypt-verify-the-identity-over-insecure-http).
3. We have another option that could be used, which isn't really implemented right now, and that is to use DNS-based Authentication of Named Entities (DANE), which is an alternative to the PKI that uses DNS and DNSSEC to store public keys in DNS records instead. DNS has it's own centralization problems, but it eliminates the need for a separate CA infrastructure.

With all this being said, why can't the grpc certificate be tied somehow to the node's public key and not fuss with the methods above? The node's public key has it's open channels affiliated with it, and those channels are sort of a way to build a weighted web of trust that may one day be able to eliminate the desire for certificate authorities. I realize that the peer to peer transport may be a widely different protocol than the grpc interface, but I'm just thinking that there could be some way to sign the grpc certificate using the peer to peer transport's public key. We also have the <pubkey>@host format that is typically used to connect to a peer. This is easy to copy and paste, put in QR codes, etc.. Seems like this approach may be better than needing to copy certificate files over if we can use it to bootstrap the security of the grpc certificate.

[Roasbeef]

With all this being said, why can't the grpc certificate be tied somehow to the node's public key and not fuss with the methods above?

Totally can be, we have a new project coming out soon that implements this. The idea is just to use the node public key, and then use the same crypto handshake as we use for the LN p2p protocol over gRPC. So then this way, all you need is a new fresh public key, and everything works as normal.

[AndySchroder]

Is your new gRPC protocol going to use https. or will you run http and then wrap everything in your own encryption? Just wondering how this might be compatible with existing gRPC libraries that are more general than for use with lnd.

[guggero]

The problem with using the node's public key as the TLS/HTTPS key is that you need to unlock the wallet to be able to use the private key to sign stuff. But the unlocking mechanism works through gRPC and you certainly don't want to submit your wallet password through unauthenticated/unencrypted gRPC. So this would only work with the auto-unlocking feature enabled that reads the wallet password from a file on startup.

[AndySchroder]

With all this being said, why can't the grpc certificate be tied somehow to the node's public key and not fuss with the methods above?

Totally can be, we have a new project coming out soon that implements this. The idea is just to use the node public key, and then use the same crypto handshake as we use for the LN p2p protocol over gRPC. So then this way, all you need is a new fresh public key, and everything works as normal.

@Roasbeef , are you talking about https://lightning.engineering/posts/2021-11-30-lightning-node-connect-deep-dive/ ? Curious if you are going to release any other client implementations for Lightning Node Connect? Seems like a really cool alternative, but I have no way of using it in my applications without python libraries being available and the documentation that you've published (in non-code form) is fairly high level, so I don't know where to start to make my own Lightning Node Connect client library.