All- there has been back and forth about the current draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing context for a new reader to understand the purpose of ARC and how the components fit together.
Cribbing from DKIM, I'm proposing a Protocol Elements section, which would replace section 4 of the current draft. I believe this section provides the missing context, and allows a significant amount of other explanatory text and additional sections to be removed or condensed. Because I haven't written something like this before, I wanted to get the working group's feedback on the proposal (below), its content, ordering, and anything else that should (or should not) be there before submitting as an I-D. Feedback please! Seth -------- 4 Protocol Elements As with SPF, DKIM, and DMARC, ARC makes no claims about the contents of the email message it has sealed. However, for a valid and passing ARC chain, a Final Receiver is able to ascertain: * all domains that claim responsibility for modifying the email message in transit; * participating domains that claim responsibility for handling but not modifying the message; * and trace information, including: * the [7601] authentication results each participating ADMD saw; * and otherwise missing data needed to complete a DMARC report for the sending domain; Given this information, a Final Receiver is able to make a determination if message delivery around a DMARC failure is warranted per local policy. Every participant in an ARC Chain, except for the originating sender and Final Receiver, are both an ARC Validator and then an ARC Sealer. The validated chain status must be passed to the sealer in order for sealing to occur properly; how this is done is considered ADMD specific and an implementation detail. INFORMATIONAL: It is important to understand that validating and then immediately sealing a message leaves no room for message modification, and many early implementations of ARC did not initially work because both operations were performed in the same pass. The following Protocol Elements are conceptual parts and design decisions of the protocol that are not specific to either Validators or Sealers, but ensure the ARC Chain conveys this information to a Final Receiver. 4.1 Chain of Custody At a high level, an ARC Chain represents a chain of custody of authentication and other trace information (AAR) surrounding a message, signed by each handler of the message. Each link in the chain (AMS) is designed to be brittle, insofar as it survives only until the next modification of the message. However, the overarching information around who added links and what they claimed responsibility for (AS) is designed to remain intact over the entirety of the chain. An ARC chain that is valid and passing has the attributes listed above in [X]. An ARC chain that is invalid or does not pass can make none of these claims. Until ARC usage is widespread, there will continue to be intermediaries that modify messages but do not ARC seal. As with a failing DKIM signature (https://tools.ietf.org/html/rfc6376#section-6.3), a failing ARC Chain SHOULD be treated the same as a message with no ARC Chain. [[ NOTE TO WORKING GROUP: This paragraph probably is better places in Verifier actions; I’ll move it when I suggest language for that, but am surfacing it now in case the WG believes it belongs here/has problems with this statement in general. ]] 4.2 Participation is optional Validating an existing Chain and then adding your own ARC Set to a message allows you to claim responsibility for modifications done by your ADMD to benefit message delivery downstream. However, no ADMD is obligated to perform these actions. 4.3 Only one ARC Chain A message can have only one ARC Chain on it at a time. Once broken, the chain cannot be restarted, as the chain of custody is no longer valid and responsibility for the message has been lost. 4.4 Benign nature of an ARC Set Even when an ARC chain is valid and passes, its use is limited to very specific cases. An ARC Chain only adds value to a Final Receiver evaluating message delivery in the context of a DMARC failure. An ARC Chain in general, and an ARC Set in particular, were designed to only add useful information, and otherwise be benign. Specifically: * adding an ARC set to a message does not damage or invalidate an existing Chain; * validating a message exposes no new threat vectors [see:Security Considerations:DNS Overhead]; INFORMATIONAL: The ability to ARC Seal safely if an ADMD is unsure if it will be modifying a message is crucial to the success and adoption of the protocol. Some larger ADMDs ARC Seal all inbound mail, so that if messages are modified within their ADMD they can be ARC Sealed again on egress. This is a feature of ARC, not a bug. 4.5 Key Management The public keys for ARC header fields follow the same requirements, syntax and semantics as those for DKIM signatures, described in Section 3.6 of {{RFC6376}}. ARC places no requirements on the selectors and/or domains used for the ARC header field signatures. 4.6 Trace Information ARC includes trace information encoded in the AAR. While section [AAR] defines what information must be provided, Sealing ADMDs may provide additional information, and Validating receivers may use or ignore this Trace information as they wish. [[ NOTE TO WG: There is a separate section I’m writing on The ARC Experiment that will go into more detail on trace information, that this section should reference. ]] 4.7 Instance Tags [[ NOTE TO WG: Exactly the same as https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09#section-4 - it will need some cleanup later ]] X.8 Chain Validation Status [[ NOTE TO WG: Exactly the same as https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09#section-5.3.1 ]] 4.9 All failures are permanent Due to the nature of transmission of ARC Chains across multiple intermediaries, all errors, even temporary ones, become unrecoverable and are considered permanent. Any error validating or sealing a chain, for whatever reason, should be treated the same and MUST result in a “cv=fail” verdict.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
