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

[VENKATRAMAN RAMAKRISHNA <[e-mail]>]

Thomas,

I’m reviewing your earlier proposal quite late, but I hope my comments are still useful.

The security analysis looks good to me. Perhaps you can state explicitly that confidentiality challenges can be overcome using preexisting standards like TLS, but that integrity and denial-of-service (and resource waste) challenges do arise when either gateway is not compliant with the protocol. We can perhaps categorize the specific vectors of integrity and DoS threats:

  *   G1 allowing G2 to mint an asset without extinguishing its own asset is an integrity violation. You point how this happens in (c).
  *   G1 allowing G2 to reverse a mint decision after processing an allocation (i.e., a rollback) is a DoS attack. You point out how this happens in (a).
  *   G2 forcing a rollback at G1 after making it freeze (lock) an asset is a DoS attack. You point out how this happens in (b). In (b), I’d add how G2 may purposefully fail to send a Lock-Assertion-Receipt (2.4), thereby forcing G1 to trigger an unlock.

As a suggestion, or a recommendation, we can say that there exist recovery and failover mechanisms (defined in https://datatracker.ietf.org/doc/draft-belchior-satp-gateway-recovery/) whereby the existence of multiple redundant gateways could mitigate a single gateway’s malicious behavior. If either G1 or G2 fail to comply with the protocol as per your list, backup gateways may, by observing a shared log, resurrect the protocol instance. What do you think?

General question: given that this is an architecture document, does this content belong in an appendix or in the main body? Also, considering David’s question about cross-network queries, we can mention that such a feature is desirable though not in scope for the SATP-Core spec, which is concerned purely with an asset transfer session and not with post hoc audit and dispute resolution (a Stage 4, if you will).

Rama

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

Thanks David, These are great inputs. >>> 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!1m-vTR6zRvmalYv7WOBlIPq3Vz5GZm47h6JUwaumghV9F4miATUp9FhNmbWrsTzTrAlw1-EOFzHBQQHDpba7pwWzF0rziH-3LB_yYkYpVJf4liIIPQLYEydsJwMaaCviH2i5NA$>   ‌
ZjQcmQRYFpfptBannerEnd
Thanks David,

These are great inputs.


>>> 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 definitely agree we will need these facilities to make the gateway useful. I think in the past couple of years the group has discussed the need for these gateway-related facilities (services).

However, right now we are constrained by the scope of the Charter which limits us to focus on the transfer flows (burn-mint) with ACID properties. Many things need to occur in Stage-0, which is out of scope currently.

If/when we expand the Charter, we should include a threats model document IMHO.


>>> 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?

I believe this this is the facility that Rama is developing in the Views draft. In fact, this question (did the burn occur) should be answerable by any gateway fronting a network NW1 (even if that gateway was not originally involved in the transfer).


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


This is part of Stage-0. In practice, gateways would need to call APIs of external identity service providers (IdP) to validate the identity of the user and the attributes of the users (e.g., are the users on the OFAC Sanctions list). This could be another new draft about how a Gateway could interact with an Identity Registry/Issuer (ala W3C Verified Credentials data model).


Best
--thomas



From: sat <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 13, 2024 at 2:32 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Sat] WG Last Call for comments: draft-ietf-satp-architecture-02
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?


  1.  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]<mailto:[e-mail]>> On Behalf Of Thomas Hardjono
Sent: Tuesday, March 12, 2024 5:32 PM
To: VENKATRAMAN RAMAKRISHNA <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[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/<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.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-HFV_fb-Xk972ls5DoWgMWW79oH20YfNH8hjCg3JlqiuFsXT2NITBT7QRPylcK8cqNSq3CDVQ6pUL0xR8KH4JB2dmkL9SjtYZgBubMWLl0x9qJWTlFfUIpU1ph2Fp4CrUIPjIw$>   ‌
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<https://www.ietf.org/mailman/listinfo/sat>

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

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