From f335dc1789f1ac657973b760307d15443b8dbf35 Mon Sep 17 00:00:00 2001 From: Antoine Riard Date: Sun, 8 Nov 2020 20:44:28 -0500 Subject: [PATCH] WIP Oracle validation Closes #97 --- Oracle-Validation.md | 102 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 Oracle-Validation.md diff --git a/Oracle-Validation.md b/Oracle-Validation.md new file mode 100644 index 0000000..085b4bf --- /dev/null +++ b/Oracle-Validation.md @@ -0,0 +1,102 @@ +# Client-Side Oracle Validation + +# Table of Contents + +* [Abstract](#abstract) +* [General Requirements](#general-requirements) +* [Oracle-Discovery](#oracle-discovery) +* [Oracle-Validation](#oracle-validation) + + +## Abstract + +The DLC protocol relies on trust-minimized oracles mapping real-world events to signatures, those ones +then confidentially re-mapped by participants to a range of contract outcomes. A participant expected +execution of the DLC is thus function of the oracle well-behaving as announced before event +realization. In this current protocol version, oracle behavior is assumed to be trusted. This level +of trust is expressed by the client oracle selection policy, and should faithfully reflect user +oracle preferences. + +Oracle signature usage requires confidence that the associated `oracle_public_key` is owned by the +correct remote subject (person, system or organization). The ownership is asserted by having the +client verifying a signature which is bound to an identity anchor (domain name, LN node pubkey, ...). +The evaluation of identity anchor correctness is beyond the scope of this protocol. A DLC client may +use this identity anchor as a descriptor for a reputation system. + +# Oracle Discovery + +Actually, no oracle discovery protocol support is mandated. The following requirements are generic +requirements, which should be swayed from only if protocol has higher built-in privacy mechanisms. + +## Requirements + +A node: +* MUST persist its keyring across restart/shutdown. +* SHOULD fetch any `oracle_public_key` advertised by a "good reputation" oracle. + +## Rationale + +A DLC client should desynchronize any oracle pubkey fetching from DLC contract setting, otherwise +the fetched entity may deduce an usage of oracle upcoming events. By fetching any `oracle_public_key` + available, a DLC client is hindering better potential oracle usage among a wider anonymous set. +"Good-reputation" is enforced by the client oracle selection policy and its definition is beyond this +current specification. + +# `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 +oracle. + +## Requirements + +A node: +- SHOULD NOT fetch `oracle_public_key` if it's not 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` +- if `oracle_event` signature is not valid against the `oracle_public_key`: + - MUST reject the `offer_dlc` + +## Rationale + +Fetching `oracle_public_key` at `offer_dlc` is a privacy leak vector for the message receiver. +Assuming oracle keys fetching is done through some privacy-preserving channel, if the DLC +counterparty can trigger communications through this channel it might hinder DLC client anonymity +toward the oracle. + +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 +be signed, and thus losing timevalue of collaterals. + +# `oracle_attestation` Authentication + +## Requirements + +A node: +- if an `oracle_attestation` has not been requested by the DLC client: + - MUST reject the `oracle_attestation`, even if message is valid +- if an announcement for this `event_id` hasn't been previously accepted OR announcement's `oracle_public_key` and attestation's `oracle_public_key` are not equal: + - MUST reject the `oracle_attestation` +- if the range of `signatures` is not valid against the nonces committed in the accepted announcement + - MUST reject the `oracle_attestation` + +## Rationale + +Rejecting unrequested `oracle_attestation` prevents attestations injection by an attacker to discover +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. + +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 ? + +# Authors + +Antoine Riard + +![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY") +
+This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).