From lf-lists at mattcorallo.com Fri Aug 25 19:30:45 2023 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Fri, 25 Aug 2023 12:30:45 -0700 Subject: [Lightning-dev] Disclosure: Fake channel DoS vector In-Reply-To: References: Message-ID: <54da586f-0c95-7988-13b7-c43dedbbb25a@mattcorallo.com> 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 > and > https://github.com/lightningdevkit/rust-lightning/issues/59 > > [1] https://github.com/lightningdevkit/rust-lightning/blob/main/GLOSSARY.md#monitor-replicas > > [2] https://github.com/bitcoin/bips/pull/1382 > > Le?jeu. 24 ao?t 2023 ??01:36, Matt Morehouse > 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 > . > > - Matt > > [1] https://github.com/ElementsProject/lightning/releases/tag/v23.02 > > [2] https://github.com/ACINQ/eclair/releases/tag/v0.9.0 > > [3] https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114 > > [4] https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev