BOLT1: Add support for network message padding (feature ??)

[tnull]

Previous research 1, 2 has shown that the Lightning Network is susceptible to passive network-layer attacks on privacy that can exploit metadata leaking from transmitted network messages.

While other factors such as timing come into play, the most severe information leakage is due to the fact that a passive adversary monitoring the Noise-encrypted network traffic can still observe clearly distinguished network message sizes, which allows them to reliably classify messages by type, and therefore in turn allows them to draw conclusions on node behavior. In the worst case, this allows a purely passive off-path adversary able to monitor traffic of multiple nodes on a payment path to not only observe that a payment took place, but also to identify the payment's endpoints.

To mitigate the information leakage coming from observable network message sizes, we here propose the introduction of option_message_padding, a simple protocol that allows Lightning counterparties to opt into padding network messages to fixed size thresholds large enough to cover update_add_htlc messages by including suitably sized TLV records in all sent TLV stream extensions.

This approach will lead to uniform message size distribution for 'normal' day-to-day operations. Note however that messages beyond the chosen size threshold will still stand out and leak some amount of information. Moreover, note that we abstained from including padding for custom messages, as it's not guaranteed that all application-layer protocols are able to handle TLV streams according to 'it's-okay-to-be-odd' rules (see #1302 for some questions around that).

A draft of a reference implementation can be found over at lightningdevkit/rust-lightning#4248

Some sidenotes on the chosen approach/current PR:

• The absence of network message padding could be considered a shortcoming of the BOLT8 transport / Noise encryption protocol. Therefore, we could also consider adding a new Noise handshake version for it and adding the padding on this layer. While this could be considered the cleaner approach, I previously received feedback from a few people that they would prefer the optional-TLV-approach proposed in this PR, which is why I went this way for now. I however would be open to discuss either approach - maybe making it a (mandatory?) part of BOLT8 would be cleaner. In particular, it would also allow us to add padding for custom messages, which the current approach doesn't necessarily allow.
• While the current proposal states that the receiver should discard the padding bytes, we could consider making use of the padding TLV, e.g., to opportunistically transmit enqueued gossip data. While this extension could result in a nice reduction of net overhead, I for now left it out of the proposal.
• For now I set feature 68/69 as a placeholder as they look to be the next free ones, but I might be missing something.

[rustyrussell]

Hmm. We already have ping messages for this? And they have the advantage that they can create completely bogus messages.

The more germane question is how to determine appropriate padding values? I haven't been able to come up with a great answer for this yet :(

[tnull]

Hmm. We already have ping messages for this?

Oh, how are ping messages connected? I agree they could be used as cover traffic once we have network message padding, i.e., all messages are the same size, but otherwise I don't see how they are connected?

The more germane question is how to determine appropriate padding values? I haven't been able to come up with a great answer for this yet :(

Yeah, in the LDK draft implementation I just chose update_add_htlc's size (including some optional fields), plus some buffer. I arrived at 1520bytes pre-encryption (1536 byes post I believe), i.e., any messages larger than that wouldn't be padded and still stick out from the anonymity set. Same goes for message types that can't be padded such as custom network messages and gossip.

Note that in the last spec meeting everybody (including me) seemed to prefer to add padding at the BOLT8 transport layer rather than going with the (arguably pretty hacky) TLV-based approach in this draft PR. There were however some confusions around whether or not this would be possible without a v2 noise/BOLT8 protocol, which I hope to discuss/clarify further in today's meeting.