While you were aware of these fixes at the time, I'd appreciate it if you, someone who hasn't spent
much time contributing to LDK over the past two or three years, stop trying to speak on behalf of
the LDK project.
Thanks,
Matt
On 8/24/23 4:33 PM, Antoine Riard wrote:
Hi Matt,
Thanks for the great work here.
Confirming the v0.0.114 release number for the LDK "fake" lightning channels
mitigations.
From the LDK-side, the vulnerability didn't come as novel knowledge, we have thought of potential
DoS issues in peer state machine handling (e.g [0]) a long time ago and our long-term design
philosophy has always been to privilege watchtower and process separation as a defense in-depth
mitigation (e.g see our glossary about "monitor replica" [1]). All those hardening architectures are
not implemented yet as part of the "vanilla" LDK (we're a library after), though it's consistent
with the answer we made privately during your disclosure.
About the lessons, a few remarks.
"Use watchtowers": note there is difference between watchtower only encompassing revoked state
punishment and "monitor replica' encompassing second-stage HTLC. For that type of DoS issues, you
wish to have the second deployed.
"Multiple process": note your Lightning node multi-process should be free of "deadlock" and other
processing contaminating bugs, i.e the chain monitoring and reaction logic should maintain
liveliness even if the off-chain state machine coordinator (let's say `ChannelManager`) got DoS /
crashed, the chain monitoring should be able to detect revoked states and react finally.
"More security auditing needed": I can only share the opinion that security and robustness has not
been the top priorities of the lightning implementations, for a very long time, I think
implementations have been more focus on spec features parity to maintain a usage market share,
rather thinking about the long-term network sustainability and safety of end-user funds. For the
more senior Lightning devs, those issues won’t come as strong surprise, I think some things like
package relay rank higher on folks priorities to mitigate publicly known and more serious security
issues [2].
Looking forward to more security auditing of the Lightning Network.
Cheers,
Antoine
[0] https://github.com/lightningdevkit/rust-lightning/issues/383
<https://github.com/lightningdevkit/rust-lightning/issues/383> and
https://github.com/lightningdevkit/rust-lightning/issues/59
<https://github.com/lightningdevkit/rust-lightning/issues/59>
[1] https://github.com/lightningdevkit/rust-lightning/blob/main/GLOSSARY.md#monitor-replicas
<https://github.com/lightningdevkit/rust-lightning/blob/main/GLOSSARY.md#monitor-replicas>
[2] https://github.com/bitcoin/bips/pull/1382
<https://github.com/bitcoin/bips/pull/1382>
Le jeu. 24 août 2023 à 01:36, Matt Morehouse <mattmoreho...@gmail.com
<mailto:mattmoreho...@gmail.com>> a écrit :
Hi list,
Last year a DoS vector was discovered to affect all node
implementations, where an attacker could open large numbers of fake
channels to the victim and never publish them on-chain, causing the
victim to consume excessive resources.
Defenses against the DoS have been shipped in the following releases:
- CLN 23.02 [1]
- eclair 0.9.0 [2]
- LDK 0.0.114 [3]
- LND 0.16.0 [4]
If you are running node software older than this, your funds may be at
risk! Update to at least the above versions to help protect your
node.
More details about the DoS vector are available at
https://morehouse.github.io/lightning/fake-channel-dos
<https://morehouse.github.io/lightning/fake-channel-dos>.
- Matt
[1] https://github.com/ElementsProject/lightning/releases/tag/v23.02
<https://github.com/ElementsProject/lightning/releases/tag/v23.02>
[2] https://github.com/ACINQ/eclair/releases/tag/v0.9.0
<https://github.com/ACINQ/eclair/releases/tag/v0.9.0>
[3] https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114
<https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114>
[4] https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta
<https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
<mailto:Lightning-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
<https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
