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

[[e-mail]]

Hi:

   I think the appendix Thomas has suggested below  belongs in a threat model document.

I don’t think RFC 5246 (TLS 1.2) is a good model.  TLS is essentially a transport protocol not an application protocol.

 

I think the architecture document should contain additional systems features such as:

 

1.	Is a query facility necessary for one gateway to verify that the other gateway has really performed critical functions?

Example:  Did Gateway 1 really extinguish the asset when it was supposed to?

 

2.	Is a facility needed so that each Gateway can  do its own authentication of  the user signed on to the other Gateway?

 

I am sure there are other facilities necessary to provide security to this process.

 

David Millman

   

From: sat <[e-mail]> On Behalf Of Thomas Hardjono
Sent: Tuesday, March 12, 2024 5:32 PM
To: VENKATRAMAN RAMAKRISHNA <[e-mail]>; [e-mail]; [e-mail]; Thomas Hardjono <[e-mail]>
Subject: Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02

 

Folks, 

 

How’s about this text for an Appendix in the SATP-Architecture.  I’m thinking we should make each paragraph short, kind of like Appendix F in RFC5246.

 

Please feel free to suggest additional bullet points on attack points in the SATP protocol run. 

 

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

Appendix A: Security Analysis

 

The SAT protocol utilizes a TLS1.2 (TLS1.3) secure channel that must be establishes between the sender gateway (G1) and the receiver gateway (G2). The two gateways must first establish this secure channel in Stage-0 before they can proceed to execute the SAT protocol. This includes both gateways verifying all the relevant parameters required for their TLS1.2 session (e.g. correct TLS endpoints, certificate validation, identity validation, etc.).

 

Assuming the two gateways have established the secure channel and have proceeded to commence the SAT protocol, there are a number of possible attacks points within the SAT protocol run that may occur if one (or both) of the gateways are dishonest. Alternatively, an attacker may target one (or both) gateways by disrupting the message exchange between gateways G1 and G2. 

 

(a) Multiple intentional aborts by the sender gateway G1:

 

A dishonest sender gateway G1 may purposely fail to continue the protocol run at certain crucial points.  One such crucial point is in Stage-3, where the gateway G1 is expected to transmit the Commit-Final Assertion message (3.5). If the gateway G1 intentionally fails to transmit this message, gateway G2 may conclude that the message has been lost and may proceed to reverse the temporary hold it has previously created (temporary asset mint in message 3.2).  Although this dishonest behavior by G1 does not cause asset damage to G2, it may exhaust computing resources at gateway G2. If network NW2 incurs transaction fees, such a reversal may be costly for gateway G2.

 

 

(b) Multiple intentional aborts by the receiver gateway G2:

 

In a similar manner, a receiver gateway G2 may also purposely fail to continue the protocol run at certain crucial points. One such point is in the Commit-Ready message (3.3) that it should transmit to G1 after receiving the commit prepare message (3.1) from G1. In this case, gateway G1 may conclude that the message is lost and simply abort the protocol run.

 

 

(c) Failure to transmit ACK-Final Receipt:

 

Another possible point of attack by a dishonest gateway G2 may occur by the gateway intentionally failing to transmit the ACK-Final-Receipt (3.7) in response to a the Commit-Final Assertion message (3.5) from gateway G1. Here, the senser gateway G1 may conclude that the message is lost and will assume that the transaction has reach finality in network NW2. The sender gateway G1 has retained the previous Lock-Assertion Receipt (2.4) in Stage-2 that was signed by G2, indicating that the gateway G2 has accepted the responsibility of ensuring that the asset-assignment (3.6) by G2 will be correctly executed. Failure by G2 to complete this task becomes a financial and legal liability for the owner of gateway G2.

 

 

(d) Other?

 

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

 

 

 

--thomas

 

 

 

 

From: VENKATRAMAN RAMAKRISHNA <[e-mail] <mailto:[e-mail]> >
Date: Tuesday, March 12, 2024 at 2:59 PM
To: Thomas Hardjono <[e-mail] <mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02

FYI, we did discuss security threats a couple of months ago on this mailing list: https://mailarchive.ietf.org/arch/msg/sat/CPTQfYeEH0acV_5ryeBdCEPAD0c/. The outcome was that “12. Threat Model Considerations” was added to the architecture draft.

 

Rama

 

From: Thomas Hardjono <[e-mail] <mailto:[e-mail]> > 
Sent: Wednesday, March 13, 2024 12:13 AM
To: VENKATRAMAN RAMAKRISHNA <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Cc: Thomas Hardjono <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02

 

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 

ZjQcmQRYFpfptBannerStart




This Message Is From an External Sender 


This message came from outside your organization. 


   <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-HFV_fb-Xk972ls5DoWgMWW79oH20YfNH8hjCg3JlqiuFsXT2NITBT7QRPylcK8cqNSq3CDVQ6pUL0xR8KH4JB2dmkL9SjtYZgBubMWLl0x9qJWTlFfUIpU1ph2Fp4CrUIPjIw$>   Report Suspicious    ‌ 

ZjQcmQRYFpfptBannerEnd

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 <[e-mail] <mailto:[e-mail]> > on behalf of VENKATRAMAN RAMAKRISHNA <[e-mail] <mailto:[e-mail]> >
Date: Tuesday, March 12, 2024 at 1:33 PM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
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 <[e-mail] <mailto:[e-mail]> > On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: Tuesday, March 12, 2024 9:45 PM
To: [e-mail] <mailto:[e-mail]> 
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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Wes Hardaker
Sent: Saturday, March 9, 2024 9:08 AM
To: [e-mail] <mailto:[e-mail]> 
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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/sat 

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

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