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

[VENKATRAMAN RAMAKRISHNA <[e-mail]>]

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]>
Sent: Wednesday, March 13, 2024 12:13 AM
To: VENKATRAMAN RAMAKRISHNA <[e-mail]>; [e-mail]; [e-mail]
Cc: Thomas Hardjono <[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>