Specify Client-Side Oracle Validation #120

ariard · 2020-12-09T00:57:40Z

A really raw WIP, I still need clarification on oracle_info/oracle_announcement formats. Also if we scope censorship-resistance of oracle-client communications.

Oracle-Validation.md

benthecarman · 2020-12-09T03:53:29Z

Oracle-Validation.md

+* MUST fetch oracle pubkey.
+* MUST fetch any oracle pubkey available.
+* MUST persist its keyring across restart/shutdown.
+


Should we also recommend a encrypted & authenticated channel so they have less of chance of being man-in-the-middle'd

Also should we add recommendations of where to obtain the oracle's keys? ie directly from oracle vs oracle explorer

Yes I think rn we don't have specific communication protocols for oracle discovery, you might have

a DNS seed (e.g BOLT 10) relying on trusting DNS servers

a manual copy-paste from few oracle repositories (e.g 1ml.com)

a oracle existence gossips network (e.g BOLT 7) with some attributes filtered by user preferences

a hardcoded initial list provided by DLC client vendors

....

Even if you answer "What's a good oracle to me ?", you still have to find the list of such "good" oracles without them being hidden or unknown from you, or if you have some central repo avoiding this one becoming a bait ?

Should we also recommend a encrypted & authenticated channel so they have less of chance of being man-in-the-middle'd

First, how do you ensure that the pubkey you're opening a E&A transport with is really owned by the entity you expect to talk with ?

Should we also recommend a encrypted & authenticated channel so they have less of chance of being man-in-the-middle'd

I don't see the point of an authenticated channel to receive oracle information if the oracle announcements (and attestations) are themselves authenticated.

Also should we add recommendations of where to obtain the oracle's keys? ie directly from oracle vs oracle explorer

I think it's up to the users who they trust more, and I don't really see a technical rational for choosing one over the other? (and thus I don't think we should recommend anything, at least at this stage).

I don't see the point of an authenticated channel to receive oracle information if the oracle > announcements (and attestations) are themselves authenticated.

It might be good to heartbeat your connections with a oracle to detect any kind of oracle censorship attempt. Wouldn't achieve its effect with unauthenticated channel. Though such heartbeat might not be great to preserve your privacy toward the oracle, trade-off...

I think it's up to the users who they trust more, and I don't really see a technical rational for choosing one over the other? (and thus I don't think we should recommend anything, at least at this stage).

Once we have lazyness/fraud proofs we might have some kind of scoring and selection engine? But overall agree too early for now..

It might be good to heartbeat your connections with a oracle to detect any kind of oracle censorship attempt. Wouldn't achieve its effect with unauthenticated channel. Though such heartbeat might not be great to preserve your privacy toward the oracle, trade-off...

Yeah not great for privacy, and I don't really see a big upside. If you get censored there is not much you can do I think? And if there is something you can do, you should be able to do it even if you detect it only at maturation time if you setup a long enough refund time lock.

Once we have lazyness/fraud proofs we might have some kind of scoring and selection engine? But overall agree too early for now..

Yes we might. But still I personally feel it will be up to the users which scoring or selection engine they'd want to chose, or if they just trust an oracle more than those. I think what I'm saying is that such considerations might not have their place in the specifications.

If you get censored there is not much you can do I think? And if there is something you can do, you should be able to do it even if you detect it only at maturation time if you setup a long enough refund time lock.

First we should dissociate oracle censorship from bitcoin p2p censorship. They may overlap or not. Secondly, you might have redundant communication channels, only enabled in case of emergency (including worst-case scenario sending a mail to a human operator to get involved). And if it's a tx-relay censorship, it might be hard to dissociate from a congestioned mempool...

That said, no a worry to address those issues now.

LLFourn · 2021-01-03T23:35:27Z

Oracle-Validation.md

+Authenticating oracle event prevents time-value DoS where a DLC is entered relying on a known honest oracle which doesn't have committed to the DLC event signing.
+
+
+TODO: sybil attack where honest connections to Olivia are censored until `refund_tx` is valid ?


What aspect of this is a sybill attack?

Depends if oracle discovery is happening through any kind of p2p mechanisms. If you learn oracle through a DNS record and the server cache is poisoned do you consider this as a sybil attack ? But yes better to call this oracle censorship, which is beyond the scope of this PR.

ariard · 2021-02-28T22:46:23Z

Finally updated this PR, incorporating new oracle_announcement/oracle_attestation.

I think this comment merits its own meeting discussion, how do we make oracle discovery accessible is a really good question.

Oracle-Validation.md

nkohen · 2021-03-01T19:58:30Z

Oracle-Validation.md

+Authenticating the `oracle_attestation` against a previously accepted announcement prevent CPU DoS
+against a DLC client feeded with expensive-to-validate messages.
+
+TODO: `oracle_attestation` should be signed against `oracle_public_key` to prevent forging of invalid `oracle_attestation` by an attacker ?


Not sure what this means? Aren't oracle_attestations unforgeable?

Olivia announces event_id=XYZ with pubkey.Olivia. It's committed by Alice and Bob in their DLC. Mallory, a malicious oracle is connected to Alice for an unrelated event_id=ABC. XYZ is a public event announcement, so Mallory might guess that Alice consumes this oracle.

When event XYZ maturity comes, Mallory feeds Alice with an attestation {event_id=XYZ, oracle_public_key=Olivia, sigs=invalid}. Is there a risk of triggering Alice to severe her connection for faulty sigs or return a specific error to Mallory leaking event_id=XYZ usage ?

In the sense that only Olivia can create a valid attestation under her announcement -- yes this is a requirement generally. Any invalid attestation should just be ignored. I don't think there is a need to sign the attestation.

Just ignoring is a good behavior, otherwise it might be exploited in weird ways. Will add a "if invalid, MUST ignore". I believe CPU DoS can't really be avoided...

Oracle-Validation.md

ariard · 2021-03-02T23:58:54Z

Addressed review comments or answered at f335dc1

Yet-to-be-solved comment.

ariard · 2021-03-03T14:22:31Z

Updated at d0f377c, requiring to ignore invalid oracle_attestations.

Ready for a new round of reviews.

Tibo-lg · 2021-03-03T21:31:41Z

Oracle-Validation.md

+other oracles actually consumed by this DLC client. Accepting unrequested _valid_ `oracle_attestation`
+and broadcasting a CET transaction on the p2p network are observable behaviors revealing DLC presenve
+for the corresponding event and oracle.


I don't really follow this part. Do you mean an unrequested oracle_attestation but for which you actually have a DLC? In that case I'm not sure how we could propagate attestation in a P2P setting.

It's all depend of we propagate messages in this p2p settings.

If it's something similar to tx-relay on the base layer, you do have an inventory-getdata-tx messages sequence. If the inventory is already known by receiver you won't emit a getdata to save on bandwidth/CPU.

If it's something like Lightning gossips, without any announcement, effectively this requirement would be a blocker to process attestations.

So yeah I agree, I think that's a small mitigation against DoS assuming our p2p network fits the first model. Likely to early as a reasoning 😅

Thanks for the clarification :)

nkohen

This will require some additional language once we merge the oracle changes (separate announcement and attestation keys, signatures from nonce keys which need to be validated) but lgtm for now

Tibo-lg

I think it will have to be revisited later but it's a good basis for iterating.

ariard · 2021-03-09T20:18:37Z

@nkohen Let me know what needs to get done on this PR. I think Lloyd is okay to land it and integrate expected changes around attestation/announcement keys later.

LLFourn

This will need to be revised very soon with oracle key changes and attestation changes (concept of attestation signature will be gone). It might be better to revise it before merging. Leave it up to you guys.

Oracle-Validation.md

LLFourn · 2021-03-08T03:32:55Z

Oracle-Validation.md

+
+Rejecting announcement for which the `oracle_public_key` hasn't been accepted by client oracle
+selection policy and announcement hasn't been authenticated prevent usage of lazy or malicious
+oracles. Authenticating event also prevent entering in a DLC position for which the event won't


what is a lazy oracle and how is it different to a malicious oracle?

I think a malicious oracle might be qualified by an equivocation proof. A lazy would be one faulting to commit to a yet-to-be-designed-and-proposed-on-the-ml-publication space :)

Note, I made the same point during my fraud point review that we should have better security definitions of notions like equivocation, invalidity, falseness and maybe lazyness. See #152

Dropping for now we can revise later.

ariard · 2021-03-10T23:04:34Z

Updated at a8cac0c integrating @LLFourn small points.

ariard · 2021-03-17T00:33:59Z

ping @nkohen :)

nkohen

Just a couple nits

nkohen · 2021-03-26T05:19:24Z

Oracle-Validation.md

+# `oracle_announcement` Authentication
+
+[`oracle_announcement`](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Oracle.md#oracle-announcements)  
+authentication happens at `offer_dlc` reception, thus verifying binding between an event and an


Isn't it also authenticated before offer_dlc construction?

IIUC your question, your suggesting that a DLC client could pre-authenticated events as soon as they're publicly announced by an oracle but before they're proposed as a contract by a counterparty ?

I think so, added a MAY likewise :
"MAY pre-validate oracle_event signature against the oracle_public_key at the time of its publication"

Beyond the really slight perf improvement, it might also avoid to fetch oracle_public_key on offer_dlc reception, that way preserve receiver anonymity towards the oracle.

nkohen · 2021-03-26T05:20:37Z

Oracle-Validation.md

+A node:
+- SHOULD NOT fetch `oracle_public_key` if it's already a member of client oracle keyring
+- if `oracle_public_key` has not been accepted by client oracle selection policy:
+    - MUST reject the `offer_dlc`


is this really a MUST and not a SHOULD? Above you say "SHOULD fetch any oracle_public_key ..."

Above is a SHOULD NOT ?

If you already know the oracle_public_key, avoid to fetch it again to preserve anonymity towards the oracle.

If you don't know the oracle_public_key, fetch it to authenticate the oracle_announcement.

If this oracle_public_key has been blacklisted by your oracle selection policy, keep it as part of you keyring, otherwise you won't be able to reject offending offer_dlc.

If this oracle_public_key has been accepted by your oracle, accept the proposed offer_dlc.

Do you have another flow in mind ? Note, you might have a size issue on your keyring, but for now let's shrug about tricky DoS.

That's a good remark, clarified with new requirements.

nkohen · 2021-03-26T05:21:47Z

Oracle-Validation.md

+selection policy and announcement hasn't been authenticated prevent usage of malicious oracles.
+Authenticating the event also prevents entering in a DLC position where the oracle never intends
+to make the attestation, and thus losing the timevalue of the collateral.
+


probably also worth mentioning that valid announcements are required in generating fraud proofs in the case of fraud later on.

Closes discreetlogcontracts#97

ariard · 2021-03-26T22:08:49Z

Thanks for the review, updated at 3f181f7 to address Nadav comments.

ariard marked this pull request as draft December 9, 2020 00:58

benthecarman reviewed Dec 9, 2020

View reviewed changes

LLFourn reviewed Jan 3, 2021

View reviewed changes

ariard force-pushed the 2020-12-oracle-validation branch from 4b533e3 to cebf2df Compare February 28, 2021 22:40

ariard marked this pull request as ready for review February 28, 2021 22:41

ariard mentioned this pull request Feb 28, 2021

Tuesday March 2 2021 Meeting #148

Merged

nkohen reviewed Mar 1, 2021

View reviewed changes

ariard force-pushed the 2020-12-oracle-validation branch from cebf2df to f335dc1 Compare March 2, 2021 23:57

ariard mentioned this pull request Mar 3, 2021

Links between Specifications Documents #60

Open

ariard force-pushed the 2020-12-oracle-validation branch from f335dc1 to d0f377c Compare March 3, 2021 14:21

Tibo-lg reviewed Mar 3, 2021

View reviewed changes

ariard force-pushed the 2020-12-oracle-validation branch from d0f377c to 80b1cd5 Compare March 5, 2021 00:59

nkohen approved these changes Mar 5, 2021

View reviewed changes

Tibo-lg approved these changes Mar 8, 2021

View reviewed changes

LLFourn reviewed Mar 9, 2021

View reviewed changes

ariard force-pushed the 2020-12-oracle-validation branch from 80b1cd5 to a8cac0c Compare March 10, 2021 23:03

LLFourn approved these changes Mar 11, 2021

View reviewed changes

nkohen reviewed Mar 26, 2021

View reviewed changes

Add Oracle validation

3f181f7

Closes discreetlogcontracts#97

ariard force-pushed the 2020-12-oracle-validation branch from a8cac0c to 3f181f7 Compare March 26, 2021 22:07

nkohen merged commit afada7d into discreetlogcontracts:master May 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Specify Client-Side Oracle Validation #120

Specify Client-Side Oracle Validation #120

ariard commented Dec 9, 2020

benthecarman Dec 9, 2020

benthecarman Dec 9, 2020

ariard Dec 9, 2020 •

edited

Loading

Tibo-lg Mar 1, 2021

ariard Mar 2, 2021

Tibo-lg Mar 3, 2021

ariard Mar 3, 2021

LLFourn Jan 3, 2021

ariard Mar 2, 2021

ariard commented Feb 28, 2021

nkohen Mar 1, 2021

ariard Mar 2, 2021

LLFourn Mar 3, 2021

ariard Mar 3, 2021

ariard commented Mar 2, 2021

ariard commented Mar 3, 2021

Tibo-lg Mar 3, 2021

ariard Mar 5, 2021

Tibo-lg Mar 5, 2021

nkohen left a comment

Tibo-lg left a comment

ariard commented Mar 9, 2021

LLFourn left a comment •

edited

Loading

LLFourn Mar 8, 2021

ariard Mar 10, 2021

ariard commented Mar 10, 2021

ariard commented Mar 17, 2021

nkohen left a comment

nkohen Mar 26, 2021

ariard Mar 26, 2021 •

edited

Loading

nkohen Mar 26, 2021

ariard Mar 26, 2021

nkohen Mar 26, 2021

ariard commented Mar 26, 2021

		Authenticating oracle event prevents time-value DoS where a DLC is entered relying on a known honest oracle which doesn't have committed to the DLC event signing.


		TODO: sybil attack where honest connections to Olivia are censored until `refund_tx` is valid ?

Specify Client-Side Oracle Validation #120

Specify Client-Side Oracle Validation #120

Conversation

ariard commented Dec 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard Dec 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard commented Feb 28, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard commented Mar 2, 2021

ariard commented Mar 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nkohen left a comment

Choose a reason for hiding this comment

Tibo-lg left a comment

Choose a reason for hiding this comment

ariard commented Mar 9, 2021

LLFourn left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard commented Mar 10, 2021

ariard commented Mar 17, 2021

nkohen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard Mar 26, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard commented Mar 26, 2021

ariard Dec 9, 2020 •

edited

Loading

LLFourn left a comment •

edited

Loading

ariard Mar 26, 2021 •

edited

Loading