Subject: [dmarc-ietf] Proposed ARC "Protocol Elements" section

From: Seth Blank <[email-masked]>
Date: Thu, 23 Nov 2017 02:18:10 +0000

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.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 29 Nov 2017 17:09:28 +0000

> and additional sections to be removed or condensed.

In general, this looks pretty good. I'll work on integrating it into the
-10 work in progress. There are a few grammatical tweaks that I'll do as I
integrate it.

--Kurt