Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02

Hey folks,

To add some context, we thought about quite a few of these 
considerations in our papers on SATP:

-https://www.techrxiv.org/articles/preprint/CBDC_bridging_between_Hyperledger_Fabric_and_permissioned_EVM-based_blockchains/21809430

-https://www.sciencedirect.com/science/article/abs/pii/S0167739X21004337

We did not add those to the specification for the reasons that Thomas 
mentioned. That said, this discussion could be a good fit for the 
appendix. Perhaps the architecture document would be better suited since 
the security model extends to crash recovery.

Rafael

A 2024-03-12 20:42, Thomas Hardjono escreveu:

> Thanks David and Rama,
> 
> One useful analogy at the protocol level is to compare the 
> function/purpose of the SATP protocol with the function/purpose TLS1.2 
> protocol (RFC5246).
> 
> The TLS1.2 spec defines the behavior of the client/server to establish 
> keys amd secure session etc., but the RFC does not say __how__ to 
> implement a TLS Server.  The server could be a standalone box, a 
> microservice in a private cloud, or on a public cloud.  In each of 
> these cases, the actual implementation quality and attack-resistance 
> will vary.
> 
> Similarly, the SATP-Architecture and SATP-Core defines the behavior of 
> gateways (which we call Client/Server in SATP-Core). It does not say 
> how to implement a Gateway in a relatively attack-resistant manner.
> 
> A useful part of RFC5246  is its Appendix F (Security Analysis), which 
> discusses some of the possible attacks and some strategies to counter 
> them.  Even there, the Appendix does not explain how to implement 
> against these attacks.
> 
> Perhaps SATP-Architecture (or SATP-Core) could be improved by adding an 
> Appendix discussing the Security Threats.
> 
> What do folks think?
> 
> Best
> 
> --thomas
> 
> From: sat <sat-bounces@ietf.org> on behalf of VENKATRAMAN RAMAKRISHNA 
> <vramakr2@in.ibm.com>
> Date: Tuesday, March 12, 2024 at 1:33 PM
> To: ladler2@bellatlantic.net <ladler2@bellatlantic.net>, sat@ietf.org 
> <sat@ietf.org>
> Subject: Re: [Sat] WG Last Call for comments: 
> draft-ietf-satp-architecture-02
> 
> David,
> 
> In my opinion, SATP doesn't require "everybody" to be honest, but just 
> requires that each counterparty network be "collectively honest", i.e., 
> maintain internal consistency and have the capacity to thwart insider 
> Byzantine failures.
> 
> Further, if a gateway acts dishonestly, "honest" counterparty networks 
> will be able to find out through an audit (which is not as satisfactory 
> as a prevention, but it may be the best we can get in a completely 
> decentralized setting.)
> 
> Your point about SATP coming under intense threat (and scrutiny, if it 
> handles large-valued assets) is very well taken though. We do need to 
> make the security assumptions and caveats crystal clear. IMO the design 
> principle of network opacity as mentioned in Section 3.1 covers the 
> point about collective network honesty as it tells users that, from 
> SATP's perspective, the network is a unitary entity that has delegated 
> asset transfer privileges to a gateway.
> 
> Rama
> 
> -----Original Message-----
> From: sat <sat-bounces@ietf.org> On Behalf Of ladler2@bellatlantic.net
> Sent: Tuesday, March 12, 2024 9:45 PM
> To: sat@ietf.org
> Subject: [EXTERNAL] Re: [Sat] WG Last Call for comments: 
> draft-ietf-satp-architecture-02
> 
> Hi:
> I have a problem with the architecture document because it contains 
> only small sections related to security.
> The SAT process will come under intense threat from external theft and 
> internal fraud.
> The architecture document focuses on a clean asset exchange where 
> everyone is honest and uses well tested software.
> 
> I am not an expert on blockchain or related technologies so the experts 
> in the WG should add to the architecture document the features 
> necessary to deal with the threats.
> 
> Question:  Do we want to revisit the architecture document when the 
> threats to the SAT process are enumerated?
> 
> David Millman
> 
> -----Original Message-----
> From: sat <sat-bounces@ietf.org> On Behalf Of Wes Hardaker
> Sent: Saturday, March 9, 2024 9:08 AM
> To: sat@ietf.org
> Subject: [Sat] WG Last Call for comments: 
> draft-ietf-satp-architecture-02
> 
> Greetings all,
> 
> The authors have requested that draft-ietf-satp-architecture-02 be 
> placed into WG last call and after a review by the chairs we agree it's 
> ready to progress forward.  I have some personal comments that I'll 
> submit during last call, but nothing substantive or process-problematic 
> that should hold up it progressing.  Thus, we have changed the 
> document's status to being in WG LC and have set a deadline of 4 weeks 
> from now.  Thus, WG LC will end on April 6th, AOE (anywhere on earth).
> 
> We encourage all participants of the WG to read the document,  suggest 
> any changes you feel are needed from simple editorial suggestions to 
> calling out major issues you find with the document.  WG participants 
> should also express their opinions about whether or not the document is 
> ready to progress and you support it's publication.
> 
> All comments should be sent to the mailing list.
> 
> --
> Wes Hardaker
> USC/ISI
> 
> --
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat
> 
> --
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat
> 
> --
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat

-- 
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico 
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/