Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (8 June 2021)

From: Thomas Hardjono <[email-masked]>
Date: Wed, 9 Jun 2021 17:46:27 +0000

Folks,

Here are the summary notes from yesterday's meeting.

As usual, please jump in to make corrections.

-- thomas --

----------------------------------------------
Summary Notes from IETF Blockchain Gateway Interoperability group meeting

Date: Tuesday 8 June 2021.

(a) Attendees:

Denis Avrilionis
Shiping Chen
Claire Facer
Martin Hargreaves
Luke Riley
Tom McGary
Michael McBride
John Robotham
Java Xu
Thomas Hardjono

(b) IETF Note Well slide

-- This group meeting operates under IETF IP Rules as described in RFC5378 and RFC8179.

(c) Gateway identification & discovery (Shiping/Thomas)

-- The gateway identification draft-00 has just been uploaded

-- URL is:  https://www.ietf.org/archive/id/draft-chen-dlt-gateway-identification-00.txt

-- The two figures are still blank, and will be added in the next revision.

-- Currently the draft discusses two basic options, namely identification/discovery at the Application Layer and Network Layer.

-- At the application layer, the driving function is the business agreement (peering agreement or contract) between two VASPs or a group of VASPs (e.g. consortium).

-- The information regarding the gateways  (i.e. gateway identifier, VASP owner, public keys & certs, etc.) could be placed in a "directory" (or list) that is shared by the VASPs. This is similar in approach to that being taken by the TRISA community (Travel Rule Information Sharing Architecture).

-- Regardless of the form of information representation (e.g. directory, list, blockchain, etc.) there is the question of access/permissions on the directory.  

-- The directory could be (should be) publicly-readable but there may be cases where members of a private decentralized ledger network (DLN) may wish for this information to be read-protected in a private directory.

-- The network layer approach was discussed at last meeting (inspired by the SMTP/MTA  model).  This approach could be combined with the directory strategy, where gateways can validate the information of peer gateways by querying the directory.

-- Tom noted that the use of the “client/wallet” in the diagram may confuse some people, because there are cases where the Originator (Alice) is the wallet-holder but there are also cases where there is a third party Wallet Provider.

-- Martin suggested that instead of “client/wallet”, simply use the term “Originator”. Shiping agrees about the potential for confusion, and will use that term in the next revision. Thomas noted that the interaction between the Originator and the Gateway in a DLN is out of scope for this draft. Basically, the draft focuses only on G1 finding G2.

-- Other ideas:  Resource PKI (RFC6480).  Mike explains that RPKI is used commonly for an AS (autonomous system, such as an ISP) to claim prefix number for blocks of IP addresses that it owns (i.e. has been assigned to it). 

-- RPKI runs out-of-band from the BGP protocol. This allows ISPs to share Route Origination Authorization (ROA), permitting one ISP to validate a claim made another ISP that it owns a given prefix. ISPs can use RPKI to prevent hijacking of prefixes by other claimants.

-- Mike continued to explain that RPKI is somewhat tied to the BGP paradigm, and so some enterprises that wish to deploy the gateway-to-gateway approach (i.e. in the draft) may not be interested in the RPKI approach.

-- Thomas asks if there was some way to “modify” RPKI to carry gateway information. Mike says it’s a big effort, but technically speaking some fields can be added. Tom mentioned that a key goal of RPKI is for an AS to assert who they say they are, and so RPKI is not so much a “discovery” mechanism but an assertion mechanism.

-- Tom suggested that the RPKI and DNSSEC should be requirements for infrastructures underlying DLNs, and thus should be mentioned in the Security Considerations section.

-- Question from Martin: in this scenario what is a gateway asserting ownership of? Tom mentions that the gateway could claim ownership of IP address (i.e. VASP owns IP address).  Martin mentions that we assume gateways will be running on top of TCP/IP, and so could assume that at the BGP layer constructs (such as RPKI and ROA flows) are already running. But the BGP and RPKI paradigm is useful to explain the gateway architecture bottom to top (i.e. to application layer where the service endpoints reside).

-- The group also discussed mechanism to identity DLNs (entire network), and how to address cases where a gateway is dual-headed in that it is participating in two separate DLNs.  Mike mentioned perhaps we need to think of some numbering scheme for DLNs. More discussion and thinking needed.

(d) Other gateway identification mechanisms (e.g. D-PKI and DIDs).

-- Thomas gave an example of the W3C DID (Decentralized Identifier) structure and VC (Verified Credential), asking if a DID could be used by a VASP to declare (self-register) its gateways.  For example, each gateway could have its own DID data structure published on the blockchain by its owner/VASP. Thus, for all the gateways belonging to a VASP, the VASP would sign the DID data structure recorded on the blockchain.

-- However, since each gateway is a unique device (all bearing the same standard ODAP service endpoint) the endpoint public-key in each DID would be different public-keys. For a given gateway, the endpoint public-key in its DID could be used to establish the TLS secure channel to that gateway.

-- Martin commented that a core issue with DIDs lies with the “roots of trust” in the entity declaring the DID (because a rogue entity could self-declare its fake gateway using the DID mechanism). This means that the VASP signing public-key has to be chained under a well-known entity such as CA in the traditional PKI model. This also why there are EV certificates that carry legal and business information regarding the VASP.

-- Thomas briefly describe the Verifiable Credential (VC) example, where the claim section carries the assertion (attribute) regarding the entity (id) whose public-key is stated in the VC data structure.

(e) Other items: 

-- The group will take a break in July (i.e.  no meetings for July).

-- Thomas will send calendar cancellations for July.

-- After July, the first August meeting will be on Tuesday August 3rd.

(f) Next meeting in June: 

-- June 22nd.

-----------------------------

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 28 Jun 2021 15:15:59 +0000

Folks,

Please feel free to add or make corrections

-- thomas --

Date: Tuesday 22 June 2021.

(a) Attendees:

Denis Avrilionis
Shiping Chen
Luke Riley
Rafael Belchior
Miguel Correia
John Robotham
Java Xu
Juan Ignacio Ibanez
Mizan Chowdury
Tom McGarry
Thomas Hardjono

(b) IETF Note Well slide

(c) Updates on drafts/docs:

-- Gateway identification & discovery (Shiping/Thomas)

     o  Thank you to Rafael and other folks for inputs.

     o  Nothing more to report today on draft-00, but Shiping & Thomas plan will be working on the next revision (including the diagrams).

-- Crash recovery (Rafael):

     o  No updates to report today, but continuing work on the draft.

-- Log storage using IPFS (Thomas):

     o  Thomas mentioned a meeting with some folks from Protocol Labs (PL), who develop IPFS and Filecoin. The potential is to use IPFS-based storage for logs in crash recovery, possibly via a Standardized APIs. Thomas will extend an invitation to PL for a presentation to this group (e.g. aiming for August).

     o  Denis mentioned that there are various other decentralized storage systems, such as Cassandra (https://dl.acm.org/doi/10.1145/1773912.1773922). So having a standardized APIs will help. Denis also mentioned a core concern with on-chain decentralized storage, namely the privacy issues around data (i.e. GDPR in the EU).

-- Escrow models (Luke):

     o  Luke will start writing-up a short draft on the various models for asset escrow/locking. This is the material Luke presented to this group a couple of meetings ago.

(d) Device Attestations Model for Gateways:

-- Since gateways may be handling digital assets carrying significant economic value, it is likely that future infrastructures implementing gateways will require that gateways perform mutual device attestations as part of Phase-1 (as a preliminary to establishing the secure TLS channel between them).

-- In Phase-1, a gateway (e.g. G2 in the destination DLN) must verify different aspects of the digital asset transfer-- each of which could be more easily viewed as different "layers" (sub-phases) of Phase-1. For example, gateway G2 will have to validate the device identity and owner (VASP V1) of gateway G1, and vice versa.  It will have to validate that DLN2 is permitted (legally) and mechanically capable to ingest the asset-type.  It has to validate that the asset has legal standing in the jurisdiction of operation of DLN2 (i.e. not some fake stable-coin or digital assets), etc. etc.

-- Part of validating "device identity" is performing mutual device attestations, where the gateways issues a signed report of its "current state" -- examples of which include the device composition and software stack used by the gateway. A gateway G2 may decline a request from G1 if the gateway G2 is configured with a policy that demands that G1 be operating using a certain approved configuration (i.e. approved set of device configurations).  If a getaway is built using trusted hardware (e.g. TPM, SGX, TrustZone) then part of attestations is proving the presence of the identity-key(s) of the trusted hardware.

-- Thomas explained the Attestation Framework that is being developed in the TCG and the IETF.  Here are some links:

     o  IETF RATS:  https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

     o  The TCG has been working on attestations since early 2000s. A new TCG Attestations will be published soon, but an early spec can be found here:

         https://trustedcomputinggroup.org/wp-content/uploads/IWG_Architecture_v1_0_r1.pdf

-- In the context of gateways, each gateway must take-on the role of an Attester. For the Attestation Evidence verification, there may multiple deployment models. In one model, a gateway may take-on the dual role of Attester and of Verifier (i.e. it has an on-board verifier). Another model is for a gateway to offload the verification of the Attestation Evidence to a third-party Verifier Service that serves the DLN (i.e. for G2 in DLN2, there will be Verifier Service VS2 that serves all gateways belonging to DLN2). In this second model, the gateway become truly a Relying Party to the Verifier Service.

-- The policies set within a gateway is referred to as Appraisal Policies for Evidence, and it is defined by the Verifier Owner.  The policies may determined by the owner of the gateway, or it may be determined by the membership of the DLN (e.g. consortium of node owners).

-- A reasonably readable paper that explains the Attestation Framework from TCG and IETF can be found here (nb. it has the same diagram used in the slides):

         https://link.springer.com/article/10.1007/s11280-021-00869-4

(e) Trustworthiness Claims for Gateways:

-- In order to provide semantically interoperable "meanings" to the attestation evidence from different types of trusted hardware, there is another draft in the IETF from Eric Voit (Cisco) defining a number of comparable "Trustworthiness Claims":

   https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/

-- For gateways, the use of a standardized set of Trustworthiness Claims allows gateways to quickly appraise the attestation evidences coming from other gateways that employ different trusted hardware.

-- We will revisit this broad topic (i.e. gateway device attestations and trustworthiness claims) again in the future, as this is of core importance to gateways and many applications (e.g. Financial Industry).  Today was just a very quick introduction.

(f) Other items:

-- The group will take a break in July (i.e.  no meetings for July). Thomas will send calendar cancellations for July.

-- Action item to invite Protocol Labs to present to the group regarding IPFS.  

-- Generally, it would be interesting and useful to the group to periodically invite technical presentations pertinent to the area of DLT gateways (nb. the one from Luke on escrow was excellent).

(g) Next meeting:

-- Tuesday August 3rd.

----------------------------------------------------------