Skip to content

Conversation

@devrandom
Copy link
Member

@devrandom devrandom commented Aug 9, 2021

This helps the signer implement the following policies (from https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md)

  • Ensure that we have a validated counterparty-signed holder commitment we can broadcast before revoking a commitment. (policies policy-v2-revoke-new-commitment-signed and policy-v2-revoke-new-commitment-valid)
  • Ensure we sign a counterparty commitment only after a revocation - there can be a maximum of two counterparty broadcastable commitments at a time (policy-v2-commitment-previous-revoked)

@codecov
Copy link

codecov bot commented Aug 9, 2021

Codecov Report

Merging #1039 (608ed12) into main (4368b56) will decrease coverage by 0.02%.
The diff coverage is 84.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1039      +/-   ##
==========================================
- Coverage   90.82%   90.80%   -0.03%     
==========================================
  Files          65       65              
  Lines       32890    32917      +27     
==========================================
+ Hits        29872    29889      +17     
- Misses       3018     3028      +10     
Impacted Files Coverage Δ
lightning/src/ln/msgs.rs 89.10% <ø> (ø)
lightning/src/chain/keysinterface.rs 94.68% <25.00%> (-0.68%) ⬇️
lightning/src/util/enforcing_trait_impls.rs 89.28% <80.55%> (-1.10%) ⬇️
lightning/src/util/test_utils.rs 82.33% <89.47%> (+0.04%) ⬆️
lightning/src/ln/channel.rs 88.73% <100.00%> (+0.03%) ⬆️
lightning/src/ln/functional_tests.rs 97.41% <100.00%> (-0.09%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4368b56...608ed12. Read the comment docs.

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch from f7f300e to 3f1c6bb Compare August 9, 2021 10:18
@devrandom devrandom changed the title Draft: Introduce EnforcementState, validate releasing revocation secret Draft: Introduce EnforcementState, validate release of revocation secret Aug 9, 2021
@devrandom devrandom changed the title Draft: Introduce EnforcementState, validate release of revocation secret Introduce EnforcementState, validate release of revocation secret Aug 9, 2021
@devrandom devrandom marked this pull request as ready for review August 9, 2021 10:21
@devrandom devrandom force-pushed the 2021-08-more-enforcement branch from 3f1c6bb to 4525790 Compare August 9, 2021 15:07
@TheBlueMatt
Copy link
Collaborator

I'm a bit confused by the security model here is - its kinda cool to have the signer receive proof that the latest counterparty commitment transaction exists, but it presumably can't broadcast it by itself (mostly cause the signer doesn't have external network access). If a tree falls in the forest....

@devrandom
Copy link
Member Author

If the node is compromised, but the signer is intact, then the signer can be attached to a clean machine. The clean machine would have software that can broadcast the saved holder transaction. This would be a disaster recovery scenario.

@TheBlueMatt
Copy link
Collaborator

TheBlueMatt commented Aug 10, 2021

Won't our watchtower take care of the enforcement?
We'll need to see a signed ack from the watchtower before proceeding ...

Yep, this.

This would be a disaster recovery scenario.

Also this.

I'm fine with this as a reasonable belt-and-suspenders, even if its not exactly within the trust model we have to assume. Sadly needs rebase cause of large things landing for 0.0.100.

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch from 4525790 to f738350 Compare August 10, 2021 07:27
@devrandom
Copy link
Member Author

Updated PR description to call out the policy checks this would support in the signer.

Also rebased.

@devrandom
Copy link
Member Author

Won't our watchtower take care of the enforcement?
We'll need to see a signed ack from the watchtower before proceeding ...

Yep, this.

To be clear, I assume we are talking about policy-v2-revoke-new-commitment-* (see updated PR description).

I don't think the watchtower helps for all attacks related to this - it just helps with breaches.

If the signer doesn't implement these policies, and allows revocation of the only valid holder tx, then we can no longer force-close. If also the balance is mostly on our side, and the attacker controls the counterparty, then they can just withhold the funds indefinitely or ask for a ransom.

So we have to ensure that we have a valid holder tx at all times. And we have to connect the signer to a clean fallback node, or have a high-availability signer setup and publish that holder tx to mitigate this scenario.

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch 4 times, most recently from 7698988 to e7ab8c8 Compare August 17, 2021 11:23
Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few questions/suggestions but basically ACK

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch 2 times, most recently from f74bb3a to f1b556a Compare August 19, 2021 07:47
Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM given Matt's brief that EnforcingSigner is pretty much just for testing

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few easy fixes but I think this is good.

fn validate_holder_commitment(&self, holder_tx: &HolderCommitmentTransaction) {
let mut state = self.state.lock().unwrap();
let idx = holder_tx.commitment_number();
assert!(idx == state.last_holder_commitment || idx == state.last_holder_commitment - 1, "expecting to validate the current or next holder commitment - trying {}, current {}", idx, state.last_holder_commitment);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can drop the == check and only keep the -1 check here (and make it an assert_eq!()).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, it seems advisable to allow replay of the last action, in case the signer is remote and the connection dropped during the call. However, could remove it here if we don't really care about illustrating that considering that this is mostly for internal tests.

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch from e1e69e0 to ba96aa8 Compare August 20, 2021 13:15
self.holder_signer.validate_counterparty_revocation(
self.cur_counterparty_commitment_transaction_number + 1,
&secret
).map_err(|_| ChannelError::Close("Failed to validate your revocation".to_owned()))?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/your/counterparty

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this one. This is a message we are sending to the counterparty, so wouldn't it be confusing to them that we are referring to them as "counterparty" instead of "you"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, elsewhere the term "Peer" is used, so I'll use that.

@devrandom devrandom force-pushed the 2021-08-more-enforcement branch from 152d8a6 to 608ed12 Compare August 28, 2021 09:04
@TheBlueMatt TheBlueMatt merged commit 731773c into lightningdevkit:main Aug 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants