search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.15k stars 363 forks source link

[Peers] Feature: More robust defense against byte-fragmentation attacks #709

Open julianknutsen opened 4 years ago

julianknutsen commented 4 years ago

@ariard pointed out the BOLT spec is incomplete wrt byte-fragmentation concerns

The first step is validation of the issue as a problem and a move to design.

TheBlueMatt commented 4 years ago

If I'm understanding this correctly, this is basically a reference towards timing attacks allowing an adversary to determine messages sizes. I don't think its worth worrying about that - you can pretty trivially observe it just looking at the packet flow. Maybe I misunderstood the issue here.

ariard commented 4 years ago

I don't think its worth worrying about that - you can pretty trivially observe it just looking at the packet flow.

The issue is understood, it's easy to observe the packet flow at the networking layer, assuming your adversary is an infrastructure entity. What is left is all the other cases where you're not on a classic Internet stack (e.g ham radio) or doing path-aware routing. As the Rust-Lightning P2P is explicitly scoping non-traditional deployment it could be interesting to harden against such attack and mask cipher boundaries ("Is this looks like commitment_signed I can drop to trigger a channel force-close ?")

Though, not something worthy to worry now, @julianknutsen maybe we need a label to dissociate between short-term follow-up and nice-to-have-at-the-long-term ?

TheBlueMatt commented 4 years ago

As the Rust-Lightning P2P is explicitly scoping non-traditional deployment it could be interesting to harden against such attack and mask cipher boundaries ("Is this looks like commitment_signed I can drop to trigger a channel force-close ?")

I still don't think there's anything we can do - you really have two cases, either the user, at a higher level, uses constant bandwidth to mask the flow (cool!), in which case timing attacks are hidden by the flow-hiding, or they aren't, in which case you can observe the flow. The two problems are, in any scenario I see immediately, the same.

julianknutsen commented 4 years ago

As far as the process, I think this depends on where you come from. If the source is the backlog meta issue the categorization is already there.

If not, there isn't a good way to tell. This could be a prelude item in the description or a label. This is an existing problem with the rest of the issues that are all combined as well so experimenting with something and seeing how hard it is to maintain seems like the right way.

Labels can get out of hand, but as long as the team periodically reviews if they are servicing their purpose and addresses any issues I think that is a fine solution.