Revocation enforcement #764

devrandom · 2020-12-05T11:59:56Z

We want to make sure that we don't sign revoked transactions.

Given that ChannelKeys (actually EnforcingChannelKeys) are not singletons and revocation enforcement is stateful, we need to store the revocation state in KeysInterface.

This builds on #761. The first new commit "Use TestKeysInterface in functional tests" could be folded in to that PR.

codecov · 2020-12-05T17:11:48Z

Codecov Report

Merging #764 (142b0d6) into main (21a44da) will increase coverage by 0.04%.
The diff coverage is 96.26%.

@@            Coverage Diff             @@
##             main     #764      +/-   ##
==========================================
+ Coverage   91.24%   91.28%   +0.04%     
==========================================
  Files          37       37              
  Lines       22846    22920      +74     
==========================================
+ Hits        20845    20922      +77     
+ Misses       2001     1998       -3

Impacted Files	Coverage Δ
lightning/src/util/enforcing_trait_impls.rs	`90.19% <80.76%> (-9.81%)`	⬇️
lightning/src/chain/keysinterface.rs	`93.47% <100.00%> (+0.17%)`	⬆️
lightning/src/ln/chanmon_update_fail_tests.rs	`97.56% <100.00%> (ø)`
lightning/src/ln/functional_test_utils.rs	`95.13% <100.00%> (+<0.01%)`	⬆️
lightning/src/ln/functional_tests.rs	`97.18% <100.00%> (+0.23%)`	⬆️
lightning/src/ln/onchaintx.rs	`94.02% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`84.78% <100.00%> (+1.10%)`	⬆️

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 21a44da...142b0d6. Read the comment docs.

devrandom · 2020-12-05T17:57:39Z

I'm seeing a fuzzing problem, but after trying to fix it, looks like there's an actual out of order revocation.

The fuzz target is: TARGET=chanmon_consistency HEX=2d321d51ffff0b1030341d51ffff0b100a2d

devrandom · 2020-12-07T13:00:32Z

Fuzzing issue fixed

lightning/src/util/enforcing_trait_impls.rs

TheBlueMatt

One nit.

lightning/src/util/enforcing_trait_impls.rs

TheBlueMatt · 2021-01-11T20:25:34Z

lightning/src/ln/functional_tests.rs

@@ -7411,7 +7407,7 @@ fn test_data_loss_protect() {
 	tx_broadcaster = test_utils::TestBroadcaster{txn_broadcasted: Mutex::new(Vec::new())};
 	fee_estimator = test_utils::TestFeeEstimator { sat_per_kw: 253 };
 	persister = test_utils::TestPersister::new();
-	monitor = test_utils::TestChainMonitor::new(Some(&chain_source), &tx_broadcaster, &logger, &fee_estimator, &persister);
+	monitor = test_utils::TestChainMonitor::new(Some(&chain_source), &tx_broadcaster, &logger, &fee_estimator, &persister, &keys_manager);


Hmm, at least here, maybe elsewhere - dont we create the TestKeysInterface a few lines up, meaning we lose the state tracking?

This is done, but together with the fix for the other nit, a significant issue was uncovered in data_loss_protect handling.

It looks like the Node Drop implementation does a serialization round-trip, which ends up trying to broadcast a revoked commitment tx, since we restored an old state. This seems to be an actual issue with channel reestablish - not sure how you intended it to recover going forward since it's out of sync. It seems like if there's data-loss, we have to update our commitment number instead of just erroring in channel_reestablish?

Hmm, can you push the branch that demonstrates that somewhere? I suppose the "right" answer could be to not panic, return an Err, make sure ChannelMonitor handles that fine (it should?) and then hope we can broadcast the current state when our counterparty broadcasts theirs. That's not quite enough because we should be able to broadcast the old state manually, but then it'd be up to the signer to accept a stale state if we give up waiting on our counterparty.

I suppose we could tweak the signer to check a boolean whether we should panic or not and in a few tests (like this one), let it Err instead of panicing and then test that we can still claim a counterparty-broadcasted tx or retry broadcasting our state later.

Sorry, pushed now, forgot yesterday.

It seems like full support for data_loss_protect would entail putting the system in a state where it doesn't try to go on-chain, because we don't have the needed data for a non-revoked tx. Punting on that for later, I've added a commit that marks the node as failed and doesn't try to execute Node::Drop for the node that suffered the data-loss in test_data_loss_protect.

As discussed elsewhere, we now return Err when there is a revocation issue and err_on_sign_revoked_holder_tx is on in TestKeysInterface / EnforcingChannelKeys.

... however, this workaround no longer works as a result of OnChainTx.holder_commitment no longer being optional. As part of that change, we panic if an Err is return when trying to sign the latest commitment. Also, this is now an issue also in tests that test justice reactions by simulating a bad actor - they panic during HTLC claims when they react to their own broadcast.

I see a couple of approaches:

propagate the Err up the call stack and don't panic

simulate bad actor / data loss more accurately by rolling back the signer or at least the revocation counter

The rebase that fails tests was pushed just now.

Actually, the simplest fix is to disable the revocation enforcement for these spots.

devrandom · 2021-01-13T22:50:30Z

Due to issues described in #775, test_data_loss_protect isn't quite right, but we're not going to fix this right now.

The panic has been changed to an Err.

TheBlueMatt · 2021-01-13T23:06:21Z

The panic has been changed to an Err.

Can we have the test enforcing signer have an internal setting to either panic or return an Err so we still ensure we hit panics in most tests, with a comment pointing to the new issue in test_data_loss_protect.

devrandom · 2021-01-14T01:40:42Z

Added err_on_sign_revoked_holder_tx. The issue is mentioned at the top of test_data_loss_protect

TheBlueMatt

This looks good mod the fuzzers failing to compile. One nit bug no need to fix it now.

lightning/src/util/enforcing_trait_impls.rs

This allows stateful validation in EnforcingChannelKeys

We want to make sure that we don't sign revoked transactions. Given that ChannelKeys are not singletons and revocation enforcement is stateful, we need to store the revocation state in KeysInterface.

devrandom · 2021-01-19T02:01:18Z

Ran into an issue in #764 (comment) after rebase, will look into possible approaches.

devrandom · 2021-01-20T00:04:05Z

Ran into an issue in #764 (comment) after rebase, will look into possible approaches.

This has been corrected, and the PR is ready for final review.

ariard

Just minor comments otherwise SGTM.

lightning/src/util/enforcing_trait_impls.rs

devrandom · 2021-01-21T19:22:42Z

Added some more docs, please take a look. I believe this addresses all outstanding comments.

When simulating a bad actor that broadcasts a revoked tx, the policy check would otherwise panic.

ariard · 2021-01-25T18:18:35Z

Post-Merge Code Review ACK 142b0d6

devrandom mentioned this pull request Dec 5, 2020

Add a new method read_chan_signer to KeysInterface #761

Merged

devrandom force-pushed the revoke-enforcement branch 2 times, most recently from 8bbb6d6 to 3e82940 Compare December 5, 2020 16:58

devrandom force-pushed the revoke-enforcement branch 2 times, most recently from 27b2eee to dff0448 Compare December 7, 2020 12:32

devrandom changed the title ~~Revoke enforcement~~ Revocation enforcement Dec 7, 2020

devrandom force-pushed the revoke-enforcement branch from dff0448 to c602db1 Compare December 7, 2020 13:02

arik-so reviewed Dec 15, 2020

View reviewed changes

lightning/src/util/enforcing_trait_impls.rs Outdated Show resolved Hide resolved

lightning/src/util/enforcing_trait_impls.rs Outdated Show resolved Hide resolved

lightning/src/util/enforcing_trait_impls.rs Show resolved Hide resolved

devrandom force-pushed the revoke-enforcement branch 3 times, most recently from 07e0a82 to 9b840d7 Compare January 9, 2021 02:09

TheBlueMatt approved these changes Jan 11, 2021

View reviewed changes

lightning/src/util/enforcing_trait_impls.rs Outdated Show resolved Hide resolved

TheBlueMatt reviewed Jan 11, 2021

View reviewed changes

devrandom force-pushed the revoke-enforcement branch 3 times, most recently from a1644a2 to c8bd159 Compare January 13, 2021 22:47

TheBlueMatt approved these changes Jan 15, 2021

View reviewed changes

lightning/src/util/enforcing_trait_impls.rs Outdated Show resolved Hide resolved

devrandom force-pushed the revoke-enforcement branch 2 times, most recently from 10a87ba to ebc80c3 Compare January 15, 2021 02:36

devrandom added 3 commits January 18, 2021 11:59

Use TestKeysInterface in functional tests

2cbb835

This allows stateful validation in EnforcingChannelKeys

Revocation enforcement in signer

a5869b9

We want to make sure that we don't sign revoked transactions. Given that ChannelKeys are not singletons and revocation enforcement is stateful, we need to store the revocation state in KeysInterface.

Fix fuzzing issue with revocation

bd4345d

devrandom force-pushed the revoke-enforcement branch from ebc80c3 to 29d46ce Compare January 19, 2021 01:59

devrandom force-pushed the revoke-enforcement branch from 29d46ce to 592399a Compare January 20, 2021 00:02

devrandom force-pushed the revoke-enforcement branch 2 times, most recently from f240e4a to 55f4ef8 Compare January 20, 2021 00:07

ariard reviewed Jan 20, 2021

View reviewed changes

lightning/src/util/enforcing_trait_impls.rs Outdated Show resolved Hide resolved

lightning/src/util/enforcing_trait_impls.rs Show resolved Hide resolved

lightning/src/util/enforcing_trait_impls.rs Show resolved Hide resolved

devrandom force-pushed the revoke-enforcement branch from 55f4ef8 to f8e0405 Compare January 21, 2021 19:19

Let some tests disable revocation policy check

142b0d6

When simulating a bad actor that broadcasts a revoked tx, the policy check would otherwise panic.

devrandom force-pushed the revoke-enforcement branch from f8e0405 to 142b0d6 Compare January 21, 2021 19:37

TheBlueMatt merged commit f151c02 into lightningdevkit:main Jan 25, 2021

Revocation enforcement #764

Revocation enforcement #764

Uh oh!

Conversation

devrandom commented Dec 5, 2020

Uh oh!

codecov bot commented Dec 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

devrandom commented Dec 5, 2020

Uh oh!

devrandom commented Dec 7, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

devrandom commented Jan 13, 2021

Uh oh!

TheBlueMatt commented Jan 13, 2021

Uh oh!

devrandom commented Jan 14, 2021

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

devrandom commented Jan 19, 2021

Uh oh!

devrandom commented Jan 20, 2021

Uh oh!

ariard left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

devrandom commented Jan 21, 2021

Uh oh!

ariard commented Jan 25, 2021

Uh oh!

Uh oh!

codecov bot commented Dec 5, 2020 •

edited

Loading