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

[julianknutsen]

@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]

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]

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]

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]

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.