Early Review of draft-ietf-satp-architecture-05
review-ietf-satp-architecture-05-secdir-early-orman-2024-07-14-00
Request | Review of | draft-ietf-satp-architecture-05 |
---|---|---|
Requested revision | 05 (document currently at 05) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-07-16 | |
Requested | 2024-06-18 | |
Requested by | Wes Hardaker | |
Authors | Thomas Hardjono , Martin Hargreaves , Ned Smith , Venkatraman Ramakrishna | |
I-D last updated | 2024-07-14 | |
Completed reviews |
Secdir Early review of -05
by Hilarie Orman
|
|
Comments |
This is a WG full of fairly new IETF participants developing an entirely new communication architecture, and could use an early review from secdir to make sure their proposed high-level architecture "looks safe". Feel free to contact the chairs if you have questions about the WG in general. |
|
Assignment | Reviewer | Hilarie Orman |
State | Completed | |
Request | Early review on draft-ietf-satp-architecture by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/u1X1TydnKmjupnsD-cXSUeJ_Ne8 | |
Reviewed revision | 05 | |
Result | Not ready | |
Completed | 2024-07-14 |
review-ietf-satp-architecture-05-secdir-early-orman-2024-07-14-00
Security Early Review of Secure Asset Transfer (SAT) Interoperability Architecture draft-ietf-satp-architecture Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Document editors and WG chairs should treat these comments just like any other early review comments. This document addresses an architecture for securely transferring digital artifacts between systems. The transfers must be atomic. An owner of a digital artifact initiates a transfer to an entity that has agreed to accept the artifact have it registered in another system. The architecture seems to be part of an effort to standardize banking protocols (if not all financial transactions) that are based on blockchains. The document itself does not make such an assertion, but some press releases make this clear. I'm not qualified to comment on the suitability of the proposed architecture for this or any other financial purpose. The described architecture is meant to be "secure" within its own definition of security. Again, I cannot determine if those requirements (if they exist) are necessary or sufficient for finance. The two entities that carry out a secure three-phase commit protocol for these transfers are called gateways. Each one is supposed to be a member of a network. The document frequently uses the term "network (ledger)" although there is no requirement for a ledger-based system. Nor is there are need that I can see for the gateway to be a member of any particular Internet communication network (ASN). If the gateway is able to authenticate itself to a digital asset system and has the credentials that authorize it to participate in transfers, then the IP address and network membership seem irrelevant. The document implies otherwise ("Overall this approach ensures a high degree of interoperability across these networks, where each network can operate as a true autonomous system."). One might argue that this is an application-based protocol. The heart of the document is the description of the authenticated and secure three phase commit protocol that the gateways must carry out. Is it secure for the purposes describe in the document? What are the security requirements? Suppose a system has suffered a ransomware attack and has been restored from an older version, and suppose it tries to initiate a transfer that it completed just before it was disabled. It contacts a receiver in the other system and proposes the transfer. The receiver is happy to oblige. The first system is certain that it owns the asset and will sign all assertions of ownership positively. The asset is then transferred (again) to the second system. Can the second system mint a copy of the asset? I don't think the draft specifies that as a risk, but perhaps the authors feel that the reference draft-belchior-gateway-recovery-05 covers this case? The relevant verbiage is: " the fact that an asset has been locked in NW1 must be communicated via an assertion to G2 (as the 3PC participant) in an indisputable manner. Similarly, G2 must return a signed assertion to G1 that the asset has been regenerated (minted) in NW2. These signed assertions must be verifiable by an authorized third party, in the case that disputes occur (post event) or where legal audit is required on the asset transfer. " Perhaps a later audit will detect the double transfer and hold the owners of the transferring system accountable for the error. Is this secure? It depends on the security requirements. For this an similar reasons, I cannot say anything about the architecture being suitably secure for any purpose. Much of the document is concerned with practices and procedures that are important for financial transactions. The documents mentions these things for informational purposes, and they are not requirements. Some stakeholders might find this useful, but I think it is out of place in an IETF architecture document. At any rate, I find it distracting. Questions about networks and addresses: Are the participants in this transaction, i.e. the originator and the beneficiary, required to have addresses in the same ASN as their respective gateways? I'd guess not, but I'd like to know. Is the gateway required to have an address in the same ASN as the rest of transaction processing network? Why? Is the proof of transfer available through the ASN of the gateways? How requirements ensure that an "authorized third party" can carry out a verification of the transfer? The document states "The mechanisms used to provide cryptographic proofs that an asset has been burned or minted in a given network is also out of scope." Are these proofs implicitly required? The document focuses on legally binding assertions in the protocol and third-party verification of the creation of the asset in the receiving network, but they don't seem to have any independent cryptographic proofs. Minor things: The term ACID is used before it is defined. It is used as an acronym for the "desirable properties" of asset transfer, but those properties actually include two more: liveness and third-party verification. ACIDLV? The Herlihy publication is never referenced.