Document: draft-ietf-satp-core Title: Secure Asset Transfer Protocol (SATP) Core Reviewer: Joel Halpern Review result: On the Right Track
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-satp-core-17 Reviewer: Joel Halpern Review Date: 2026-10-05 IETF LC End Date: 2026-10-09 IESG Telechat date: Not scheduled for a telechat Summary: This document is quite readable and mostly in good shape. There are a few major issues that need to be addressed before publication as a Proposed Standard RFC, as well as some minor items whose evaluation I would appreciate. Major issues: For obvious reasons, the protocol requires that the assert networks on each end have certain capabilities. I think it would help the document's clarity significantly if there were a separate section enumerating those required capabilities. For example I believe that an asset network supporting SATP needs to support locking and burning of digital assets. I presume such a call-out was omitted because it was obvious to those actively working in the space. The lock mechanism descriptions seem slightly inconsistent. Section 5.3.15 on Asset Lock Mechanism within a Network describes three common mechanisms, but does not say these are requried. In fact, the section says that what the two sides support may be different. Which made sense when I read it. But then I got to section 8.1 on the Stage one messaging, bullet 3 is the networkLockType, it is required, and it has a list of exactly three values which are permitted. I am having trouble understanding how these two sections are consistent. (Section 8.2 at least notes that future versions may expand the list. But I still wonder about the relationship to 5.3.15 which seems to say it is a local matter.) Section 9.1 on the Lock Assertion Messages states "The format of the claim is dependent on the network or system of the client and is outside the scope of this specification." I can't find anything why negotiates or communicates this format in advance so that the two parties can know whether the server will understand the clients lock assertion? Or is there for some reason no need for the server to understand this? In which case that itself requires explanation in this document. I am not sure I have gotten this right, but there appears to be a potential race condition. What if the TCP and TSL session terminates after the client sends the Commit Final Assertion Message (Commit-Final)? The asset has been removed on the sending side, but the server might or might not have been told to go ahead and finalize the created object? This seems related to the old TCP fin race problem of knowing when both sides have really communicated everything. (I hope I am simply missing something here.) This seems related to the next-to-last paragraph in section 11.5 (part of the error handling) which says that in the state I am trying to describe, the abort can't unwind the deletion. It does not seem to say what is supposed to happen on the server side to fix things? Minor issues: I wonder if readers would be helped by a subsection in section 4 of something like "security behavioral goals"? I found in reading section 5 that I was wondering why there was a need for a message digital signature (5.2) beyond the integirty and authentication provided by TLS 1.3. And similarly, why there was a need for a Payload Hash. It is unclear whether network locks are required to have a timeout. In section 8.1 the timeout is optional, depending upon the lock type. In section 8.2 the timeout is required independent of the lock type? Is there an implicit requirement that a client may only be engaging in one transfer request over a single session (single TLS connection with a single sessionID)? I think that is the intention, but I missed the text that said so. This single threading assumption then leads to the question of why several of the messages have hashes of the earlier messages from the same session. It may be that an answer to the major issue on general security behavioral assumptions above will explain why these are needed. In the transition between section 8.6 and 8.7 on the transfer initiation messages, is there any circumstance other than a malformed message that could prevent or delay the sending of the Commence Response Message (ACK-Commence)? If not, what value does the message have? Section 9.1 on the Lock Assertion Message says that "This message is sent from the client to the Lock Assertion Endpoint at the server." However, it is sent over the same TLS connection that was used in stage-1. And uses the same Session ID. So it appears that it is sent to the same party that the stage-1 messages are sent to. In what sense is it sent to the Lock Assertion Endpoint at the server? A similar question applies to references to the Commit Prepare Endpoint in section 10.1 There seems to be a general protocol design issue possibly related to attempting to tie the messages more explicitly to the stage transitions. For example, it is not obvious why one needs all four of "I have locked" "Ack that you have Locked" Please prepare to Commit" and "I have prepared to commit" when the sequence "I have locked" responded to with "I have prepared to commit" would result in fewer messages with the same properties and effective transitions. As a reader, there seem to be more messages than are needed. If the underlying connection were unreliable, then the additional messages would be more important. But it is a TLS connection. Nits/editorial comments: In section 5.3.1 on Protocol Version, the second sentence includes "Implementations not understanding a future option value should..." I presume this means not understanding a future Protocol Version, and the reference to "option" is a cut-and-paste artifact? I wonder if it would be helpful to readers to include an explanation or citation as to why RATS [RFC9334] attestation is required in section 7. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
