Re: [Sat] Views

[Venkatraman Ramakrishna <[e-mail]>]

Rafael,

Sorry for replying so late to your questions.

>>>Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct?

The network of G2 is enforcing the security by validating the proof through its consensus mechanism. The proof itself is not being generated by G2 though; it’s being generated by G1 requesting its network (like how G1 currently gets lock/burn assertions from its network in SATP). G2 simply communicates the proof to an app or directly submits it to its network for validation.

>>>Are these additional functionalities and changes to the security model desired to be part of the core protocol or particular instantiations of the gateway (eg plugins)?

No, in fact the opposite. The data sharing mechanism we are drafting, and which is implemented in Weaver and Cacti, is even more paranoid than SATP w.r.t. trust in gateways; it does not trust gateways for integrity nor for confidentiality purposes. This is prevent gateways from either (1) tampering with data/assertions and proof, or (2) exfiltrating them to other external parties that the source network, which may be a permissioned network, does not wish to share authentic data and proofs with.

Rama


From: Tecnico Lisboa <[e-mail]>
Sent: Friday, March 24, 2023 4:50 AM
To: Venkatraman Ramakrishna <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [Sat] Views

Hello Rama, Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct? Are these additional functionalities and changes to the security model desired to be part
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hello Rama,
Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct?

Are these additional functionalities and changes to the security model desired to be part of the core protocol or particular instantiations of the gateway (eg plugins)?

Rafael


On 21 Mar 2023, at 11:26, Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>> wrote:

David,

Sorry for the inordinate delay in responding to you on this topic. (At least it was not pressing, as the “view” drafts are presently not within the SATP scope.)

Yes, supporting Views (and View Addresses) is meant to be an additional function for the gateways. I don’t recall how well this is sketched out in the drafts I linked to, but there is more work required at G2 in a view request-response protocol. G1 simply communicates messages back and forth within minimal processing (assuming the address of G2 is embedded within the View Address) whereas G2 must submit a request and collect a response from its backing network just like G2 collects evidence for a minting in SATP. I’ll try to work this out later once the SATP is more or less crystallized, but I think supporting views and addresses will require relatively minor augmentations to the features that the gateways must anyway implement for SATP.

There is a basic security problem that arises in view request and processing, but the solution for this is built into the end-to-end protocol (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-data-sharing/<https://datatracker.ietf.org/doc/draft-ramakrishna-sat-data-sharing/>) in the following ways:

  1.  The gateway (G2 specifically) is not trusted either for integrity or confidentiality purposes: it simply returns a proof generated by N/W2, and it does not have the authority (or capability) to unilaterally generate a proof that G1 or N/W1 will accept. In this respect, the trust model is different from what the SATP currently assumes.
  2.  The network being requested for a view (N/W2) will run an access control check before sending a response. If N/W2 is a blockchain/DLT, for example, this will be a consensus-driven decision executed through a smart contract. The right “proof” can’t be generated unless this access control check is passed by a quorum of honest peers.
I can’t think of other security issues. Do you see anything that is not covered here?

Regarding the utility of this procedure: this protocol was created (and implemented) to solve a particular need for the sharing of ledger (or smart contract) state from one permissioned DLT network to another, and we just extracted a common pattern and found a mechanism to handle it. The use cases draft (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-use-cases/<https://datatracker.ietf.org/doc/draft-ramakrishna-sat-use-cases/>) has examples (see Section 3).

Rama

From: sat <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 13 January 2023 00:54
To: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [Sat] Views

Hi Rama: I am referring to your two documents linked in your Oct. 17, 2022 email. In the SATP process the only use I can see for a View is to examine the Digital Asset before it is actually transferred. However, it has been stated in the WG
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd
Hi Rama:
  I am referring to your two documents linked in your Oct. 17, 2022 email.
In the SATP process the only use I can see for a View is to examine the Digital Asset
before it is actually transferred.  However, it has been stated in the WG meetings that
the details of the Digital Asset and the transfer must be specified in an agreement that
precedes the transfer.  So supporting Views is an additional function for the gateways.

Adding  the processing of Views to the gateways may be useful to support application
communications between Blockchain networks.  But the additional security problems View
processing entails is not justified unless View processing is required for SATP.
We also have a great of work to make SATP a useful protocol in the real world.

David Millman

--
sat mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sat<https://www.ietf.org/mailman/listinfo/sat>