From antoine.riard at gmail.com Sat Aug 26 12:03:24 2023 From: antoine.riard at gmail.com (Antoine Riard) Date: Sat, 26 Aug 2023 13:03:24 +0100 Subject: [Lightning-dev] Disclosure: Fake channel DoS vector In-Reply-To: <54da586f-0c95-7988-13b7-c43dedbbb25a@mattcorallo.com> References: <54da586f-0c95-7988-13b7-c43dedbbb25a@mattcorallo.com> Message-ID: Hi Matt, > 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. While this statement is blatantly false and disregards all the review and robustness hardening landed during the last two or three years, I would appreciate it from you in the conduct of your maintenance janitorial role to have more regard for the LDK users funds security rather than a "move fast and break things" attitude. As such, and with in mind all open-source ethical rules, I'll keep speaking on the behalf of the LDK project when I see fit, whether you're pleased or not. Best, Antoine Le ven. 25 ao?t 2023 ? 20:30, Matt Corallo a ?crit : > 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 > > < > 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 > > 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 > > < > 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: