Denial-of-state resolution: any plans?

[mvdbos]

As can be seen in the comment in the line below, the mechanism for raising a dispute to an non-validating notary following a denial-of-state attack is not yet worked out.
Are there any plans to work this out in the near future?

We are giving this a lot of thought recently at my company because we are nearing go-live with a few use cases and this is relevant for discussion around non-financial risk.

corda/node/src/main/kotlin/net/corda/node/services/transactions/NonValidatingNotaryFlow.kt

Line 25 in 1fc1e7d

* undo the commit of the input states (the exact mechanism still needs to be worked out).

For reference:

 /**
 * The received transaction is not checked for contract-validity, as that would require fully
 * resolving it into a [TransactionForVerification], for which the caller would have to reveal the whole transaction
 * history chain.
 * As a result, the Notary _will commit invalid transactions_ as well, but as it also records the identity of
 * the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently
 * undo the commit of the input states (the exact mechanism still needs to be worked out).
 */

See also #2971.

[mikehearn]

We're working on allowing an SGX enclave to attest to the validity of a transaction, thus enabling "semi validating notaries" where the notary doesn't see the tx data directly, but, does consume attestations of validity. So you wouldn't be able to mount a DoSt attack on such a notary.

However it's a fairly sophisticated project. No timelines for availability.

Otherwise today you have to use a validating notary to avoid it.

In case of dispute there are currently no tools or flows to support you. You'd need to retrieve the transactions from the underlying databases. If you'd like to contribute some code to assist with this please do; we're focusing on blocking such attacks rather than recovering from them. Notaries do keep track of notarisation requests though, so they aren't deniable.

What's the specific risk you're worried about? Mistakes or attacks?

[ulrikrasmussen]

I have been giving this a bit of thought also, and would like to chip in. I am a bit worried about both mistakes (bugs) and attacks effectively burning a resource. In a permissioned DLT such as Corda, DoSt could occur either because of (1) nodes that have been compromised by external attackers, or (2) a node which intentionally burns a resource and then claims to have been hacked and/or crashed and suffered data loss before it got to tell anyone else about the contents of the transaction. It is true that the notary will be able to tell who burned it, but it cannot prove definitively that the node's owner did it intentionally, so how can it actually assign blame? It cannot even tell invalid transactions from valid ones, so there are no objective measures to detect this situation reliably.

Even if we could detect it, I think that rolling back transactions is so against the core model of Corda that it isn't a viable solution, as it breaks the fundamental invariants of the data model.

SGX sounds like an interesting approach, as it retains the flexibility of the general-purpose programming model while providing security comparable to the much heavier (and limiting) cryptographic alternatives such as multi-party computation, homomorphic encryption schemes etc. The only worry I could have about SGX is that the discovery of a serious side-channel attack a la Spectre or Meltdown would compromise the whole model.

[mvdbos]

we're focusing on blocking such attacks rather than recovering from them.

I am fully with you on the prevention approach. As a matter of fact, we are working on something to prevent these attacks and I will do a talk on CordaCon on it later this month.
That said, both the SGX path and ours will take quite some time to get to production quality. Until then we will have projects in production with this risk.

What's the specific risk you're worried about? Mistakes or attacks?

As @ulrikrasmussen mentioned above, both really. We have looked into this in some detail and even though the probability of this attack might be lowish, in some use cases it could be devastating, which would still result in a high risk classification (impact*probability). In addition, an attacker would not need to have a lot of specific knowledge other than on Corda to execute this attack. I have trivial tests implemented that demonstrate it.

It could be especially damaging because there is currently no way to resolve them available and assets might be locked for quite some time. There is some description of dispute resolution on the Corda Network site, but it leaves out how to resolve it technically once everyone agrees off-ledger. And this is key. In my opinion, any such technical solution brings new other risks. One that I would *really not prefer is messing directly with the notary database of spent states by the Network Operator: IMO this is antithetical to the immutability concept of DLT. So indeed, clearly on the side of prevention over recovery.

[nargas-ritu]

Internal ticket - CORDA-4219

[peterli-r3]

Hi mvdbos

With Corda 5 coming soon, we are closing up the issues prior to Corda v4.5. Thank you for your contribution to Corda!

Please feel free to contact devrel@r3.com if you need any further information

[ulrikrasmussen]

This issue is as relevant for Corda 4.9 as it is to versions prior to 4.5. As far as I know, no changes are planned in Corda 5 that would resolve this issue - so why close it?