Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
Errr please replace 5 with 4 in the previous post. Thanks to devrandom. LL On Tue, Dec 15, 2020 at 2:43 PM Lloyd Fournier wrote: > > > It seems difficult to recommend YOLO commitment transactions becoming the > > standard way to recover funds. It could be preferable to the current system > > but even that is up for debate I guess. > > I feel like I can recommend oblivious settlements because (i) it's covert > > (like YOLO commitments txs unlike current system) and (ii) it's "what you > > see is what you get" -- you are guaranteed to recover the funds that you > > are presented with once you finally trigger the recovery > > Off list Dave correctly pointed out to me that this wasn't a very clear > picture of the situation. > After some thought, I came up with these claims that I think I can make > strongly: > > 1. Before you reveal that you are doing recovery you are guaranteed to have a > tx in hand that: > i. You can broadcast first > ii. You can choose the fee to be as high as you like > iii. Is not replaceable. > 2. If the malicious party is *not* willing to risk broadcasting a revoked tx > then you are guaranteed to recover the face value of the transaction(s) you > have in hand. > 3. An honest party is never at risk of broadcasting a revoked commitment tx. > 4. You never have to reveal that you were doing a recovery i.e. the channel > can continue (strictly preferable to 1) > > Current system has: 3 > Oblivious mutual close has: 1,2,3 > YOLO commitments has: 1,5 > > So I think the question of YOLO commitments vs oblivious mutual close is > whether paying the price of losing (2,3) is worth the upgrade from (1) to (5). > The concern with (1) is that once you broadcast to the network the > obliviously transferred "mutual close" transaction, the malicious party then > has a hint that you have lost data and they can try and broadcast a > favourable revoked transaction. > This should be very hard since in (1) you broadcast first, can choose as > large a fee as you like and the tx does not signal replaceability whereas the > revoked tx *will* signal replaceability. > I'm also personally trying to avoid losing (3) because to keep [1] applicable. > > As a side note: in YOLO commitment transactions you have to recover some > additional metadata from the other party -- in particular the compressed > revocation keys that you *should* know otherwise the channel cannot continue > to operate. So a signature on the compressed revocation keys must be given to > the other party before you lose data and returned to you when you are given > the commitment transaction upon reconnection. > This should be easy enough to do though. > > [1] > https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments > > On Tue, Dec 15, 2020 at 12:13 AM David A. Harding wrote: >> >> > The idea I'm working with in revocable signature based channels [1] is >> > to make the node lose its static secret key if it posts a revoked >> > commitment tx. This means they could lose ALL funds from ALL their >> > channels with ALL their peers if they ever broadcast a single revoked >> > commitment transaction. This would be a very bad thing to happen while >> > you're trying to recover funds. >> >> Yikes! A very bad thing indeed. I'll have to re-read about witness >> asymmetric channels; I don't think I realized that was a consequence of >> using them. > > > It's an optional feature -- see link[1] above where I just added an > explanation of it. > I actually see no reason why you couldn't apply revocable signatures to > transaction asymmetric channels (LN as it is today) you just have to overhaul > the revocation mechanism. > > In general I agree with your points that side-channels may be effective tools > to reveal whether a node has had data loss or not. > I think in both YOLO commitments and oblivious mutual close it is easy enough > to simulate data-loss up to a point to try and catch malicious peers using > side channels. > At least you don't have to ask the peer to broadcast a tx to find out! > > Cheers, > > LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
> It seems difficult to recommend YOLO commitment transactions becoming the standard way to recover funds. It could be preferable to the current system but even that is up for debate I guess. > I feel like I can recommend oblivious settlements because (i) it's covert (like YOLO commitments txs unlike current system) and (ii) it's "what you see is what you get" -- you are guaranteed to recover the funds that you are presented with once you finally trigger the recovery Off list Dave correctly pointed out to me that this wasn't a very clear picture of the situation. After some thought, I came up with these claims that I think I can make strongly: 1. Before you reveal that you are doing recovery you are guaranteed to have a tx in hand that: i. You can broadcast first ii. You can choose the fee to be as high as you like iii. Is not replaceable. 2. If the malicious party is *not* willing to risk broadcasting a revoked tx then you are guaranteed to recover the face value of the transaction(s) you have in hand. 3. An honest party is never at risk of broadcasting a revoked commitment tx. 4. You never have to reveal that you were doing a recovery i.e. the channel can continue (strictly preferable to 1) Current system has: 3 Oblivious mutual close has: 1,2,3 YOLO commitments has: 1,5 So I think the question of YOLO commitments vs oblivious mutual close is whether paying the price of losing (2,3) is worth the upgrade from (1) to (5). The concern with (1) is that once you broadcast to the network the obliviously transferred "mutual close" transaction, the malicious party then has a hint that you have lost data and they can try and broadcast a favourable revoked transaction. This should be very hard since in (1) you broadcast first, can choose as large a fee as you like and the tx does not signal replaceability whereas the revoked tx *will* signal replaceability. I'm also personally trying to avoid losing (3) because to keep [1] applicable. As a side note: in YOLO commitment transactions you have to recover some additional metadata from the other party -- in particular the compressed revocation keys that you *should* know otherwise the channel cannot continue to operate. So a signature on the compressed revocation keys must be given to the other party before you lose data and returned to you when you are given the commitment transaction upon reconnection. This should be easy enough to do though. [1] https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments On Tue, Dec 15, 2020 at 12:13 AM David A. Harding wrote: > > The idea I'm working with in revocable signature based channels [1] is > > to make the node lose its static secret key if it posts a revoked > > commitment tx. This means they could lose ALL funds from ALL their > > channels with ALL their peers if they ever broadcast a single revoked > > commitment transaction. This would be a very bad thing to happen while > > you're trying to recover funds. > > Yikes! A very bad thing indeed. I'll have to re-read about witness > asymmetric channels; I don't think I realized that was a consequence of > using them. > It's an optional feature -- see link[1] above where I just added an explanation of it. I actually see no reason why you couldn't apply revocable signatures to transaction asymmetric channels (LN as it is today) you just have to overhaul the revocation mechanism. In general I agree with your points that side-channels may be effective tools to reveal whether a node has had data loss or not. I think in both YOLO commitments and oblivious mutual close it is easy enough to simulate data-loss up to a point to try and catch malicious peers using side channels. At least you don't have to ask the peer to broadcast a tx to find out! Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
On Mon, Dec 14, 2020 at 04:31:23PM +1100, Lloyd Fournier wrote: > To be clear: The goal is to offer a cooperative settlement transaction up > front to the (possibly) recovering party -- *not a commitment transaction*. Ah, what BOLT0 calls a "mutual close". That makes a lot more sense and makes the protocol even cooler than I thought. Thanks for clarifying! > The idea I'm working with in revocable signature based channels [1] is > to make the node lose its static secret key if it posts a revoked > commitment tx. This means they could lose ALL funds from ALL their > channels with ALL their peers if they ever broadcast a single revoked > commitment transaction. This would be a very bad thing to happen while > you're trying to recover funds. Yikes! A very bad thing indeed. I'll have to re-read about witness asymmetric channels; I don't think I realized that was a consequence of using them. > What is the story with option_static_remotekey? I am interested to know how > the negotiation of that option has a security issue but I don't see how it > could. Whoops, I got myself confused. I meant option_data_loss_protect, which LND calls "static channel backups". I just git greped the bolts for "static" and copied the first plausible seeming result. :facepalm: On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote: > I don't think it's so clear that any party refusing to go go first can > be assumed to have lost data. Oh, I agree, it's definitely not clear. I just said they could "be *suspected* of having lost data". On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote: > If the rule is that the party receiving the connection is the one that > must send the oblivious signatures then a party that has both lost > data and is receiving a connection can just ignore the connection > request. > > There is plausible denyability because knowingly not answering a > request can't be distinguished from just having connection issues or > distinguished from a machine is just turned off. In many cases, the network does behave differently in different cases: $ nmap -p 80 dtrt.org ## online and port available 80/tcp open http $ nmap -p 80 newmail.dtrt.org ## online but no service listening 80/tcp closed http $ nmap -p 22 10.0.0.1 ## online but connection refused 22/tcp filtered ssh $ nmap -p 80 10.0.0.200 ## not online Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Moreover, there's the case where Bob tries to open a connection with Mallory, but Mallory immediately turns around and tries to open a connection with Bob. In that case, Bob's unavailability might look suspicious (although it could just be NAT or something else innocuous). However, beyond IP network activity, there's potentially a lot of evidence a dishonest counterparty can gather about a recently-reconnected node to evaluate the probability that it suffered a data loss. Perhaps most persuasive would be seeing what happened to that node's other channels. Were they all closed? Did the node fail to promptly broadcast a transaction with preimages trying to claim any pending HTLCs (which can be especially strong evidence if the dishonest counterparty was along the routing path for any of those HTLCs and so knows that the preimage was disclosed). The reason option_data_loss_protects works in theory is that the only way attacker Mallory can test her hypothesis that victim Bob lost data is by Mallory broadcasting an old state that Bob, if he didn't actually lose data, can use to penalize Mallory in a way that may profit Bob. In an ideal world, for every victim node that actually lost data there'd be several honeypot nodes that faked losing data in order to profit from dishonest counterparties. Unfortunately, I doubt that's the case, for two reasons: 1. You can only operate a data loss honeypot by causing a channel to be closed onchain, which is going to waste someone's fees. 2. A dishonest node may only try broadcasting an old state when their channel balance is low, near the minimum allowed by the channel reserve. The guidelines for channel reserve amounts were chosen (I believe) under the assumption that Mallory can be highly confident that Bob has the latest state, so the reserve is just the bare amount needed to prevent some annoying griefing. The reserve is probably not large enough to compensate for the work and fee-paying costs of operating data loss honeypots. That said, most nodes seem to be honest and hopefully the nodes playing with high-value channels are using some sort of live replication, so I don't think there have been any issues so far. -Dave signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
I don't think it's so clear that any party refusing to go go first can be assumed to have lost data. If the rule is that the party receiving the connection is the one that must send the oblivious signatures then a party that has both lost data and is receiving a connection can just ignore the connection request. There is plausible denyability because knowingly not answering a request can't be distinguished from just having connection issues or distinguished from a machine is just turned off. This reasoning should work well into the future because as long as machine failures are common, the node with data loss can hide in that anonymity set. And if human kind resolves all machine failures then by definition there shouldn't be lightning channel data loss. Cheers Ariel Lorenzo-Luaces On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding" wrote: >On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote: >> If c = 1 (i.e. the node is fine and it wants to continue the channel) >then >> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it >passes >> it sends the commitment blinding y back to prove that it doesn't have >the >> signature (i.e. prove c = 1). If verification fails then the node is >> malicious and it fails the channel. > >This is really cool! However, I don't understand why it's needed. >Your >goal seems to be for the sender to provide the commitment transaction >and signatures before he learns whether the receiver actually needs >them. That's just as easily accomplished by sending the data upfront >in >plain text. For example, it seems to me that both of the following >protocols provide identical utility: > >1. On every reconnection, request the plain text unsigned commitment > transaction, send a pedersen commitment, and receive the encrypted > signature(s). If c=1, verify the encrypted signature(s) and (on > success) send the blinding factor or (on failure) fail the channel > and ban the peer. If c=0, decrypt the signature(s), apply them to > the commitment transaction, and broadcast. > >2. On every reconnection, request the plain text unsigned commitment > transaction with all of its signatures, also in plain text. If our > database is intact, verify the commitment transaction and its > signatures are valid and (on success) continue or (on failure) fail > and ban. If we lost data, broadcast the commitment transaction. > >Unless I'm forgetting something, there's no reason a node shouldn't >send >its latest commitment transaction to its counterparty in plain text >(over the regular BOLT8 P2P encrypted and authenticated link). > >I think the challenge in either protocol above is deciding which peer >goes first, because whoever sends the commitment transaction reveals >what they think the current state is. Any node that refuses to go >first >can then be suspected of having lost data. BOLT2 >option_static_remotekey has this same problem, which is reasonably >mitigated IMO by LN's penalty mechanism forcing any would-be thief to >risk their own funds; this doesn't work for basic eltoo, though. > >-Dave > > > > >___ >Lightning-dev mailing list >Lightning-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
