]> LinkedIn

1000 West Maude Ave Sunnyvale California 94085 USA kurta@linkedin.com

Google

blong@google.com

Valimail

seth@valimail.com

TDP

superuser@gmail.com

art DMARC Working Group Internet-Draft The Authenticated Received Chain (ARC) protocol provides an authenticated “chain of custody” for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message’s authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries.

The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) is impacted by the processing of Internet Mail by intermediate handlers. This impact is thoroughly documented in the defining documents for SPF and DKIM and further discussed in and . DMARC also relies upon SPF and DKIM authentication mechanisms. Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected. Authenticated Received Chain (ARC) creates a mechanism for individual Internet Mail Handlers to add their authentication assessment to a message’s ordered set of handling results. ARC encapsulates the authentication assessment in a DKIM signature derivative to grant other handlers the ability to verify the authenticity of the individual assessment assertion as well as the aggregate set and sequence of results. Ordered sets of authentication assessments can be used by ARC-enabled Internet Mail Handlers to inform message handling disposition, to identify where alteration of message content might have occurred, and to provide additional trace information for use in understanding message handling paths.

ARC is loosely based on concepts from evidence collection. Evidence is usually collected, labeled, stored, and transported in specific ways to preserve the state of evidence and to document all processing steps.

In ARC’s situation, the “evidence” is a message’s authentication assessment at any point along the delivery path between origination and final delivery. Determination of message authentication can be affected when intermediate handlers modify message content (header fields and/or body content), route messages through unforeseen paths, or change envelope information. The authentication assessment for a message is determined upon receipt of a message and documented in the Authentication-Results header field(s). ARC extends this mechanism to survive transit through intermediary ADMDs. Because the first-hand determination of an authentication assessment can never be reproduced by other handlers, the assertion of the authentication assessment is more akin to testimony by a verifiable party than hard evidence which can be independently evaluated.

“Custody” refers to when an Internet Mail Handler processes a message. When a handler takes custody of a message, the handler becomes a custodian and attaches their own evidence (authentication assessment upon receipt) to the message if they are ARC-enabled. Evidence is added in such a way so that future handlers can verify the authenticity of both evidence and custody.

The “chain of custody” of ARC is the entire set of evidence and custody that travels with a message.

Any ARC-enabled Internet Mail Handler can validate the entire set of custody and the authentication assessments asserted by each party to yield a valid Chain of Custody. If the evidence-supplying custodians can be trusted, then the validated Chain of Custody describes the (possibly changing) authentication assessment as the message traveled through various custodians. Even though a message’s authentication assessment might have changed, the validated chain of custody can be used to determine if the changes (and the custodians responsible for the changes) can be tolerated.

This section defines terms used in the rest of the document. Readers should to be familiar with the contents, core concepts, and definitions found in . The potential roles of transit services in the delivery of email are directly relevant. Language, syntax (including some ABNF constructs), and concepts are imported from DKIM . Specific references to DKIM are made throughout this document. The following terms are imported from : ADministrative Management Domain (ADMD), Section 2.3 Message Transfer Agents (MTA), Section 4.3.2 Message Submission Agent (MSA), Section 4.3.1 Message Delivery Agent (MDA), Section 4.3.3 Syntax descriptions use Augmented BNF (ABNF) and . The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

introduces three (3) ARC header fields which are added to a message by an ARC-enabled internet mail handler. Together, these three header fields compose a single “ARC Set”. An ARC Set provides the means for an Internet Mail Handler to attach an authentication assessment to a message in a manner that can be verified by future handlers. A single message can contain multiple ARC Sets. In general concept terms, an ARC Set represents Evidence and Custody.

The sequence of ARC Sets attached to a message at a given time is called the Authenticated Received Chain. An Authenticated Received Chain is the record of individual authentication assessments as a message traverses through ARC-participating ADMDs. The first attachment of an ARC Set to a message causes an Authenticated Received Chain to be created. Additional attachments of ARC Sets cause the Authenticated Received Chain to be extended. In General concept terms, an Authenticated Received Chain represents Chain of Custody.

Internet Mail Handlers process and deliver messages across the Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as defined in . Throughout this document the term “intermediaries” refers to the both regular MTAs as well as delivery/reposting agents such as mailing lists covered within the scope of ’s transit services. “Intermediaries” and “Internet Mail Handlers” are used synonymously throughout this document.

The Authentication Assessment which is affixed to a message as part of each ARC Set consists of the “authres-payload” . For the integrity of an ARC Set, the Authentication Assessment only needs to be properly encapsulated within the ARC Set as defined below . The accuracy or syntax of the authres-payload field does not affect the validity of the ARC chain itself.

Signing is the process of affixing a digital signature to a message as a header field, such as when a DKIM-Signature (as in section 2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a complete and valid ARC Set to a message creating or continuing an Authenticated Received Chain.

A Sealer is an Internet Mail Handler that attaches a complete and valid ARC Set to a message. In general concept terms, a Sealer adds its testimony (assertion of authentication assessment) and proof of custody to the Chain of Custody.

A Validator is an ARC-enabled Internet Mail Handler that evaluates an Authenticated Received Chain for validity and content. The process of evaluation of the individual ARC Sets that compose an Authenticated Received Chain is described in . In general concept terms, a Validator inspects the Chain of Custody to determine the content and validity of individual Evidence supplied by custodians.

The following ABNF tokens are imported: tag-list ( section 3.2) authres-payload ( section 2.2) cfws ( section 3.2.2)

The following ABNF tokens are used elsewhere in this document:

ARC introduces three new header fields. Syntax for new header fields adapts existing specifications. This document only describes where ARC-specific changes in syntax and semantics differ from existing specifications.

The ARC-Authentication-Results (AAR) header field records the message authentication assessment as processed by an ARC-participating ADMD at message arrival time. In general concept terms, the AAR header field is where Evidence is recorded by a custodian. The AAR header field is similar in syntax and semantics to an Authentication-Results field , with two (2) differences: the name of the header field itself; the presence of the “instance tag”. Additional information on the “instance tag” can be found in . The formal ABNF for the AAR header field is:

Because there is only one AAR allowed per ARC set, the AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD, regardless of how many Authentication-Results header fields are attached to the message.

The ARC-Message-Signature (AMS) header field allows an ARC-participating ADMD to convey some responsibility (custodianship) for a message and possible message modifications to future ARC-participating custodians. In general concept terms, the AMS header field identifies a custodian. The AMS header field has the same syntax and semantics as the DKIM-Signature field , with three (3) differences: the name of the header field itself; no version tag (“v”) is defined for the AMS header field. As required for undefined tags (in ), if seen, a version tag MUST be ignored; the “i” (AUID) tag is not imported from DKIM; instead, this tag is replaced by the “instance tag” as defined in ; ARC places no requirements on the selectors and/or domains used for the AMS header field signatures. The formal ABNF for the AMS header field is:

To reduce the chances of accidental invalidation of AMS signatures: AMS header fields are added by ARC-participating ADMDs as messages exit the ADMD. AMS header fields SHOULD be attached so that any modifications made by the ADMD are included in the signature of the AMS header field. Authentication-Results header fields MUST NOT be included in AMS signatures as they are likely to be deleted by downstream ADMDs (per Section 5). ARC-related header fields (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) MUST NOT be included in the list of header fields covered by the signature of the AMS header field. To preserve the ability to verify the integrity of a message, the signature of the AMS header field SHOULD include any DKIM-Signature header fields already present in the message.

The ARC-Seal (AS) header field permits ARC-participating ADMDs to verify the integrity of AAR header fields and corresponding AMS header fields. In general concept terms, the AS header field is how custodians bind their authentication assessments (testimonial) into a Chain of Custody so that Validators can inspect individual evidence and custodians. The AS header field is similar in syntax and semantics to DKIM-Signatures , with the following differences: the “i” (AUID) tag is not imported from DKIM; instead, this tag is replaced by the “instance tag” as defined in ; the signature of the AS header field does not cover the body of the message and therefore there is no ‘bh’ tag. The signature of the AS header field only covers specific header fields as defined in ; no body canonicalization is performed as the AS signature does not cover the body of a message; only “relaxed” header field canonicalization ( section 3.4.2) is used; the only supported tags are “i” (from of this document), and “a”, “b”, “d, “s”, “t” from Section 3.5. Note especially that the DKIM “h” tag is NOT allowed and if found, MUST result in a cv status of “fail” (for more information see ); an additional tag, “cv” (“seal-cv-tag” in the ARC-Seal ABNF definition) is used to communicate Chain Validation Status to subsequent ADMDs. ARC places no requirements on the selectors and/or domains used for the AS header field signatures. The formal ABNF for the AS header field is:

In internationalized messages many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by and Authentication-Results as updated in , but are called out here for emphasis. In all ARC header fields, the d= s= tags can contain U-labels. In all tags, non-ASCII characters need not be quoted in dkim-quoted-printable. The AAR header allows UTF-8 in the same places that A-R does, as described in .

An “ARC Set” is a single collection of three ARC header fields (AAR, AMS, and AS). ARC header fields of an ARC Set share the same “instance” value. By adding all ARC header fields to a message, an ARC Sealer adds an ARC Set to a message. A description of how Sealers add an ARC Set to a message is found in .

Instance tags describe which ARC header fields belong to an ARC Set. Each ARC header field of an ARC Set shares the same instance tag value. Instance tag values are integers that begin at 1 and are incremented by each addition of an ARC Set. Through the incremental values of instance tags, an ARC Validator can determine the order in which ARC Sets were added to a message. Instance tag values can range from 1-50 (inclusive). INFORMATIONAL: The upper limit of 50 was picked based on some initial observations reported by early working group members. The value was chosen so as to balance the risk of excessive header field growth against expert opinion regarding the probability of long-tail but non-looping multiple-intermediary mail flows. Longer ARC chains will also impose load on validators and DNS to support additional verification steps. Observed quantities of “Received” header fields was also considered in establishing this as an experimental initial value. Valid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm. For handling multiple signing algorithms, see .

An Authenticated Received Chain is an ordered collection of ARC Sets. As ARC Sets are enumerated sets of ARC header fields, an Authenticated Received Chain represents the output of message authentication assessments along the handling path of ARC-enabled processors. Authentication Assessments determined at each step of the ARC-enabled handling path is present in an Authenticated Received Chain in the form of AAR header fields. The ability to verify the identity of message handlers and the integrity of message content is provided by AMS header fields. AS header fields allow messages handlers to validate the assertions, order and sequence of the Authenticated Received Chain itself. In general concept terms, an Authenticated Received Chain represents a message’s Chain of Custody. Validators can consult a message’s Chain of Custody to gain insight regarding each custodian of a message and the Evidence collected by each custodian.

The state of the Authenticated Received Chain at a specific processing step is called the “Chain Validation Status”. Chain Validation Status information is communicated in several ways: the AS header field in the “cv” tag, and as part of Authentication-Results and AAR header field(s). Chain Validation Status has one of three possible values: none: There was no Authenticated Received Chain on the message when it arrived for validation. Typically, this occurs when a message is received directly from a message’s original Message Transfer Agent (MTA) or Message Submission Agent (MSA), or from an upstream Internet Mail Handler that is not participating in ARC handling. fail: The message contains an Authenticated Received Chain whose validation failed. pass: The message contains an Authenticated Received Chain whose validation succeeded.

ARC-enabled Internet Mail Handlers generally act as both ARC Validators (when receiving messages) and ARC Sealers (when sending messages onward, not originated locally). An Authenticated Received Chain with a Chain Validation Status of “pass” (or “none”) allows Internet Mail Handlers to ascertain: all ARC-participating ADMDs that claim responsibility for handling (and possibly modifying) the message in transit; the authentication assessments of the message as determined by each ADMD (from AAR header fields). With this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing.

To “seal” a message, an ARC Sealer adds an ARC Set (the three ARC header fields AAR, AMS, and AS) to a message. All ARC header fields in an ARC Set share the same instance tag value. To perform Sealing (aka to build and attach a new ARC Set), the following actions must be taken by an ARC Sealer when presented with a message: All message modifications (including adding DKIM-Signature header field(s)) MUST be performed before Sealing. If the message already contains an Authenticated Received Chain with the most recent AS reporting “cv=fail”, then there is no need to proceed and the algorithm stops here. Calculate the instance value: if the message already contains an Authenticated Received Chain, the instance value is 1 more than the highest instance number found in the Authenticated Received Chain. If no Authenticated Received Chain exists, the instance value is 1. Using the calculated instance value, generate and attach a complete ARC set to the message as follows: Generate and attach an ARC-Authentication-Results header field as defined in . Generate and attach an ARC-Message-Signature header field as defined in . Generate and attach an ARC-Seal header field using the AS definition found in , the prescribed headers defined in , and the Chain Validation Status as determined during ARC Validation.

The ARC-Seal is generated in a manner similar to how DKIM-Signatures are added to messages (, section 3.7), with explicit requirements on the header fields and ordering of those fields. The signature of an AS header field signs a canonicalized form of the ARC Set header field values. The ARC set header field values are supplied to the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time of Sealing the message. Within an ARC Set, header fields are supplied to the hash function in the following order: ARC-Authentication-Results ARC-Message-Signature ARC-Seal Note that when an Authenticated Received Chain has failed validation, the signing scope for the ARC-Seal is modified as specified in .

In the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set header fields created by the MTA which detected the malformed chain, as if this newest ARC Set was the only set present. INFORMATIONAL: This approach is mandated to handle the case of a malformed or otherwise invalid Authenticated Received Chain. There is no way to generate a deterministic set of AS header fields () in most cases of invalid chains.

A message can have only one Authenticated Received Chain on it at a time. Once broken, the chain cannot be continued, as the chain of custody is no longer valid and responsibility for the message has been lost. For further discussion of this topic and the design restriction which prevents chain continuation or re-establishment, see .

ARC is not solely intended for perimeter MTAs. Any Internet Mail Handler MAY seal a message by adding a complete ARC set, whether or not they have modified or are aware of having modified the message. For additional information, see .

The utility of an Authenticated Received Chain is limited to very specific cases. Authenticated Received Chains are designed to provide additional information to an Internet Mail Handler when evaluating messages for delivery in the context of authentication failures. Specifically: Properly adding an ARC Set to a message does not damage or invalidate an existing Authenticated Received Chain. Sealing an Authenticated Received Chain when a message has not been modified does not negatively affect the chain. Validating a message exposes no new threat vectors (see ). An ADMD may choose to Seal all inbound messages whether or not a message has been modified or will be retransmitted.

A validator performs the following steps, in sequence, to process an Authenticated Received Chain. Canonicalization, hash functions, and signature validation methods are imported from section 5. Collect all ARC Sets currently attached to the message. If there are none, the Chain Validation Status is “none” and the algorithm stops here. The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist the Chain Validation Status is “fail” and the algorithm stops here. In the following algorithm, the maximum discovered ARC instance value is referred to as “N”. If the Chain Validation Status of the highest instance value ARC Set is “fail”, then the Chain Validation status is “fail” and the algorithm stops here. Validate the structure of the Authenticated Received Chain. A valid ARC has the following conditions: Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS). The instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition. The “cv” value for all ARC-Seal header fields MUST NOT be “fail”. For ARC Sets with instance values > 1, the values MUST be “pass”. For the ARC Set with instance value = 1, the value MUST be “none”. If any of these conditions are not met, the Chain Validation Status is “fail” and the algorithm stops here. Validate the AMS with the greatest instance value (most recent). If validation fails, then the Chain Validation Status is “fail” and the algorithm stops here. OPTIONAL: Determine the “oldest-pass” value from the ARC Set by validating each prior AMS beginning with the N-1 and proceeding in decreasing order to the AMS with the instance value of 1: If an AMS fails to validate (for instance value “M”), then set the oldest-pass value to the lowest AMS instance value which passed (M+1) and go to the next step (there is no need to check any other (older) AMS header fields). This does not affect the validity of the Authenticated Received Chain. If all AMS header fields verify, set the oldest-pass value to zero (0). Validate each AS beginning with the greatest instance value and proceeding in decreasing order to the AS with the instance value of 1. If any AS fails to validate, the Chain Validation Status is “fail” and the algorithm stops here. If the algorithm reaches this step, then the Chain Validation Status is “pass”, and the algorithm is complete. The end result of this Validation algorithm SHOULD be included within the Authentication-Results header field for the ADMD. As with a DKIM signature ( section 6.3) which fails verification, a message with an Authenticated Received Chain with a Chain Validation status of “fail” MUST be treated the same as a message with no Authenticated Received Chain. INFORMATIONAL: Recipients of an invalid or failing Authenticated Received Chain can use that information as part of a wider handling context. ARC adoption cannot be assumed by intermediaries; many intermediaries will continue to modify messages without adding ARC Seals.

Authenticated Received Chains represent the traversal of messages through one or more intermediaries. All errors, including DNS failures, become unrecoverable and are considered permanent. Any error validating an Authenticated Received Chain results in a Chain Validation Status of “fail”. For further discussion of this topic and the design restriction which prevents chain continuation or re-establishment, see .

If an ARC Validator determines that the incoming message fails authentication checks (potentially including ARC validation), the Validator MAY signal the breakage through the extended SMTP response code 5.7.29 “ARC validation failure” and corresponding SMTP basic response code. Validators MAY use the more general 5.7.28 “Multiple authentication checks failed” instead.

Chain Validation Status (described in ) is communicated via Authentication-Results (and AAR) header fields using the auth method “arc”. This auth method is described in . If necessary data is available, the ptypes and properties defined in SHOULD be recorded in an Authentication-Results header field: smtp.remote-ip - The address of the connection-initiating SMTP server, from which the message is being relayed. header.oldest-pass - The instance number of the oldest AMS that still validates, or 0 if all pass.

This section explores several messaging handling use cases that are addressed by ARC.

When an intermediary ADMD adds an ARC Set to a message’s Authenticated Received Chain (or creates the initial ARC Set), the ADMD communicates its authentication assessment to the next ARC-participating ADMD in the message handling path. If ARC-enabled ADMDs are trusted, Authenticated Received Chains can be used to bridge administrative boundaries.

Message services are available to perform anti-spam, anti-malware, and anti-phishing scanning. Such services typically remove malicious content, replace HTTP links in messages with sanitized links, and/or attach footers to messages advertising the abilities of the message scanning service. These modifications almost always break signature-based authentication (such as DKIM). Scanning services typically require clients to point MX records of an Internet domain to the scanning service. Messages destined for the Internet domain are initially delivered to the scanning service. Once scanning is performed, messages are then routed to the client’s own mail handling infrastructure. Re-routing messages in this way almost always breaks path-based authentication (such as SPF). Message scanning services can attach Authenticated Received Chains to messages to communicate authentication assessment into client ADMDs. Clients can then benefit from the message scanning service while processing messages as if the client’s infrastructure were the original destination of the Internet domain’s MX record.

Large message processing infrastructure is often divided into several processing tiers that can break authentication information between tiers. For example, a large site may maintain a cluster of MTAs dedicated to connection handling and enforcement of IP-based reputation filtering. A secondary cluster of MTAs may be dedicated and optimized for content-based processing of messages. Authenticated Received Chains can be used to communicate authentication assessment between processing tiers.

Mailing lists take delivery of messages and re-post them to subscribers. A full description of authentication-related mailing list issues can be found in Section 3.2.3. Mailing list services can implement ARC to convey the authentication assessment of posted messages sent to the list’s subscriber base. The ADMDs of the mailing list subscribers can then use the Authenticated Received Chain to determine the authentication assessment of the original message before mailing list handling.

Intermediaries often break authentication through content modification, interfere with path-based authentication (such as SPF), and strip authentication results (if an MTA removes Authentication-Results header fields). Authenticated Received Chains allow ARC Validators to: identify ARC-enabled ADMDs that break authentication while processing messages; gain extended visibility into the authentication-preserving abilities of ADMDs that relay messages into ARC-enabled ADMDs. Through the collection of ARC-related data, an ADMD can identify handling paths that have broken authentication. An Authenticated Received Chain allows an Internet Mail Handler to potentially base decisions of message disposition on authentication assessments provided by different ADMDs.

DMARC introduces a policy model where Domain Owners can request email receivers to reject or quarantine messages that fail DMARC alignment. Interoperability issues between DMARC and indirect email flows are documented in . Authenticated Received Chains allow DMARC processors to consider authentication assessments provided by other ADMDs. As a matter of local policy, a DMARC processor MAY choose to accept the authentication assessments provided by an Authenticated Received Chain when determining if a message is DMARC compliant. When an Authenticated Received Chain is used to determine message disposition, the DMARC processor can communicate this local policy decision to Domain Owners as described in .

DMARC-enabled receivers indicate when ARC Validation influences DMARC-related local policy decisions. When an ARC-enabled handler generates a DMARC report, it MAY indicate the influence of ARC on their local policy decision(s) by adding a reason of “local_policy” with a comment string (per Appendix C) containing a list of data discovered during ARC Validation, which at a minimum includes: the Chain Validation Status, the domain and selector for each AS, the originating IP address from the first ARC Set:

none fail fail local_policy arc=pass as[2].d=d2.example as[2].s=s2 as[1].d=d1.example as[1].s=s3 remote-ip[1]=10.10.10.13 ]]>

In the above example DMARC XML reporting fragment, data relating to specific validated ARC Sets are enumerated using array syntax (eg, “as[2]” means AS header field with instance value of 2). d2.example is the Sealing domain for ARC Set #2 (i=2) and d1.example is the Sealing domain for ARC Set #1 (i=1). Depending on the reporting practices of intermediate message handlers, Domain Owners may receive multiple DMARC reports for a single message. Receivers of DMARC reports should be aware of this behaviour and make the necessary accommodations.

The Authenticated Received Chain provides a verifiable record of the handlers for a message. This record may include Personally Identifiable Information such as IP address(es) and domain names. Such information is also included in existing non-ARC related header fields such as the “Received” header fields.

The Security Considerations of and apply directly to this specification. As with other domain authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the semantic content of messages.

Inclusion of Authenticated Received Chains into messages may cause issues for older or constrained MTAs due to increased total header field size. Large header field blocks, in general, may cause failures to deliver or other outage scenarios for such MTAs. ARC itself would not cause problems.

The validation of an Authenticated Received Chain composed of N ARC Sets can require up to 2*N DNS queries (not including any DNS redirection mechanisms which can increase the total number of queries). This leads to two considerations: An attacker can send a message to an ARC participant with a concocted sequence of ARC Sets bearing the domains of intended victims, and all of them will be queried by the participant until a failure is discovered. DNS caching and the difficulty of forging the signature values should limit the extent of this load to domains under control of the attacker. Query traffic pattern analysis may expose information about downstream validating ADMD infrastructure. DKIM only performs one DNS query per signature, while ARC can introduce many (per chain). Absent caching, slow DNS responses can cause SMTP timeouts; and backlogged delivery queues on Validating systems. This could be exploited as a DoS attack.

Recipients are cautioned to treat messages bearing Authenticated Received Chains with the same suspicion applied to all other messages. This includes appropriate content scanning and other checks for potentially malicious content. ARC authenticates the identity of some email handling actors. It does not make any assessment of their trustworthiness. Just as passing message authentication is not an indication of message safety, forwarding that information through the mechanism of ARC is also not an indication of message safety. Even if all ARC-enabled ADMDs are trusted, ADMDs may have become compromised, may miss unsafe content, or may not properly authenticate messages.

Recipients are cautioned to treat every Sealer of the ARC Chain with suspicion. Just as with a validated DKIM signature, responsibility for message handling is attributed to the Sealing domain, but whether or not that Sealer is a malicious actor is out of scope of the authentication mechanism. Since ARC aids message delivery in the event of an authentication failure, ARC Sealers should be treated with suspicion, so that a malicious actor cannot Seal spam or other fraudulent messages to aid their delivery, too.

Since ARC inherits heavily from DKIM, it has similar attack vectors. In particular, the Replay Attack described in section 8.6 is potentially amplified by ARC’s chained statuses. In an ARC replay attack, a malicious actor would take an intact and passing ARC Chain, and then resend it to many recipients without making any modifications that invalidate the latest AMS or AS. The impact to a receiver would be more DNS lookups and signature evaluations. This scope of this attack can be limited by caching DNS queries and following the same signing scope guidance from section 5.4.1.

[[ Note to the RFC Editors: “dkim - header - s” is defined in . Please adjust the list below as appropriate. ]] This draft introduces three new headers fields and updates the Email Authentication Parameters registry with one new authentication method and several status codes.

This draft adds one Auth Method with three Codes to the IANA “Email Authentication Result Names” registry: Auth Method : arc Code: “none”, “pass”, “fail” Specification: &SELF; 2.2 Status: active

This draft adds several new items to the Email Authentication Methods registry, most recently defined in : Method: arc Definition: &SELF; ptype: smtp Property: remote-ip Value: IP address of originating SMTP connection Status: active Version: 1 Method: arc Definition: &SELF; ptype: header Property: oldest-pass Value: The instance id of the oldest validating AMS, or 0 if they all pass (see ) Status: active Version: 1 Method: dkim Definition: ptype: header Property: s Value: value of signature “s” tag Status: active Version: 1

This specification adds three new header fields to the “Permanent Message Header Field Registry”, as follows: Header field name: ARC-Seal Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): &SELF; Related information: Header field name: ARC-Message-Signature Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): &SELF; Related information: Header field name: ARC-Authentication-Results Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): &SELF; Related information:

The following value should be added to the registry, as follows: Code: X.7.29 Sample Text: ARC validation failure Associated basic status code: 550 Description: This status code may be returned when a message fails multiple authentication checks, including ARC validation Reference: &SELF; Submitter: K. Andersen Change controller: IESG

The ARC protocol is designed to address common interoperability issues introduced by intermediate message handlers. Interoperability issues are described in and . As the ARC protocol is implemented by Internet Mail Handlers over time, the following should be evaluated in order to determine the success of the protocol in accomplishing the intended benefits.

In an attempt to deliver legitimate messages that users desire, many receivers use heuristic-based methods to identify messages that arrive via indirect delivery paths. ARC will be a success if the presence of Authenticated Received Chains allows for improved decision making when processing legitimate messages, specifically resulting in equal or better delivery rates than achieve through the use of heuristic approaches.

ARC should function without introducing significant new vectors for abuse (see ). If unforeseen vectors are enabled by ARC, then this protocol will be a failure. Note that weaknesses inherent in the mail protocols ARC is built upon (such as DKIM replay attacks and other known issues) are not new vectors which can be attributed to this specification.

The following open questions are academic and have no clear answer at the time of the development of the protocol. However, additional deployments should be able to gather the necessary data to answer some or all of them.

Data should be collected to show if the ARC-Seal (AS) provides value beyond the ARC Message Signature (AMS) for either making delivery decisions or catching malicious actors trying to craft or replay malicious chains.

Any selectors and/or (sub)domains (under the control of the sealing ADMD) may be used for ARC header field signatures. While implementers may choose to use various selectors and/or domains for ARC set header fields, no compelling argument for or against such usage has been made within the working group. As such we have chosen to allow maximum freedom for the experimental definition of this protocol. Wider deployment experience and higher volumes of traffic may show whether this is useful.

Longer Authenticated Received Chains will require more queries to retrieve the keys for validating the chain. While this is not believed to be a security issue (see ), it is unclear how much overhead will truly be added. This is similar to some of the initial processing and query load concerns which were debated at the time of the DKIM specification development. Data should be collected to better understand usable length and distribution of lengths found in valid Authenticated Received Chains along with the DNS impact of processing Authenticated Received Chains. An effective operational maximum will have to be developed through deployment experience in the field.

There are several edge cases where the information in the AAR can make the difference between message delivery or rejection. For example, if there is a well known mailing list that seals with ARC but doesn’t do its own initial DMARC enforcement, an Internet Mail Handler with this knowledge could make a delivery decision based upon the authentication information it sees in the corresponding AAR header field. Certain trace information in the AAR is useful/necessary in the construction of DMARC reports. Further, certain receivers believe the entire set of trace information would be valuable to feed into machine learning systems to identify fraud and/or provide other signals related to message delivery. At this point, however, it is unclear what trace information will be valuable for all receivers, regardless of size. Data should be collected on what trace information receivers are using that provides useful signals that affect deliverability, and what portions of the trace data are left untouched or provide no useful information. Since many such systems are intentionally proprietary or confidential to prevent gaming by abusers, it may not be viable to reliably answer this particular question. The evolving nature of attacks can also shift the landscape of “useful” information over time.

[[ Note to the RFC Editor: Please remove this section before publication along with the reference to . ]] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. This information is known to be correct as of the eighth interoperability test event which was held on 2018-03-17 at IETF101. For a few of the implementations, later status information was available as of August 2018.

Organization: Google Description: Internal production implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Production - Incoming Validation Coverage: Full spec implemented as of Licensing: Proprietary - Internal only Implementation Notes: Full functionality was demonstrated during the interop testing on 2018-03-17. Contact Info: arc-discuss@dmarc.org

Organization: AOL Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Beta Coverage: ARC Chain validity status checking is operational, but only applied to email addresses enrolled in the test program. This system conforms to Licensing: Proprietary - Internal only Implementation Notes: 2017-07-15: Full functionality verified during the interop testing. 2018-06: Partially retired but still accessible by special request due to the in process evolution of the AOL mail infrastructure to the integrated OATH environment. The implementation was based on the Apache James DKIM code base and may be contributed back to that project in the future. Contact Info: arc-discuss@dmarc.org

Organization: dkimpy developers/Scott Kitterman Description: Python DKIM package Status of Operation: Production Coverage: 2017-07-15: The internal test suite is incomplete, but the command line developmental version of validator was demonstrated to interoperate with the Google and AOL implementations during the interop on 2017-07-15 and the released version passes the tests in arc_test_suite with both python and python3. Licensing: Open/Other (same as dkimpy package = BCD version 2) Contact Info: https://launchpad.net/dkimpy

Organization: TDP/Murray Kucherawy Description: Implementation of milter functionality related to the OpenDKIM and OpenDMARC packages Status of Operation: Beta Coverage: Built to support Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Implementation Notes: Known issues have been resolved with release X Contact Info: arc-discuss@dmarc.org, openarc-users@openarc.org

Organization: Mailman development team Description: Integrated ARC capabilities within the Mailman 3.2 package Status of Operation: Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman package - GPL Implementation Notes: Appears to work properly in at least one beta deployment, but waiting on acceptance of the pull request into the mainline of mailman development Contact Info: https://www.gnu.org/software/mailman/contact.html

Organization: Copernica Description: Web-based validation of ARC-signed messages Status of Operation: Beta Coverage: Built to support Licensing: On-line usage only Implementation Notes: Released 2016-10-24 Requires full message content to be pasted into a web form found at http://arc.mailerq.com/ (warning - https is not supported). An additional instance of an ARC signature can be added if one is willing to paste a private key into an unsecured web form. 2017-07-15: Testing shows that results match the other implementations listed in this section. Contact Info: https://www.copernica.com/

Organization: Rspamd community Description: ARC signing and verification module Status of Operation: Production, though deployment usage is unknown Coverage: Built to support Licensing: Open source Implementation Notes: 2017-06-12: Released with version 1.6.0 2017-07-15: Testing during the interop showed that the validation functionality interoperated with the Google, AOL, dkimpy and MailerQ implementations Contact Info: https://rspamd.com/doc/modules/arc.html and https://github.com/vstakhov/rspamd

Organization: FastMail Description: Email domain authentication (sign and/or verify) module, previously included SPF / DKIM / DMARC, now has ARC added Status of Operation: Production, deployment usage unknown Coverage: Built to support Licensing: Open Source Implementation Notes: 2017-12-15: v0.50 released with full test set passing for ARC Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/

Organization: FastMail Description: Email domain authentication milter, uses MAIL::DKIM (see above) Status of Operation: Initial validation completed during IETF99 hackathon with some follow-on work during the week Coverage: Built to support Licensing: Open Source Implementation Notes: 2017-07-15: Validation functionality which interoperates with Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, the signing functionality was reported to be working 2017-07-20: ARC functionality has not yet been pushed back to the github repo but should be showing up soon Contact Info: https://github.com/fastmail/authentication_milter

Organization: Sympa Dev Community Description: Work in progress Status of Operation: Work in progress Coverage: unknown Licensing: open source Implementation Notes: 2018-01-05: Tracked as https://github.com/sympa-community/sympa/issues/153 Contact Info: https://github.com/sympa-community

Organization: Oracle Description: Status of Operation: Initial development work during IETF99 hackathon. Framework code is complete, crypto functionality requires integration with libsodium Coverage: Work in progress Licensing: Unknown Implementation Notes: 2018-03: Protocol handling components are completed, but crypto is not yet functional. Contact Info: Chris Newman, Oracle

Organization: MessageSystems/SparkPost Description: OpenARC integration into the LUA-enabled Momentum processing space Status of Operation: Beta Coverage: Same as OpenARC Licensing: Unknown Implementation Notes: Initial deployments for validation expected in mid-2018. Contact Info: TBD

Organization: Exim developers Status of Operation: Operational; requires specific enabling for compile. Coverage: Full spec implemented as of Licensing: GPL Contact Info: exim-users@exim.org Implementation notes: Implemented as of Exim 4.91

Organization: Halon Status of Operation: Operational as of May 2018 Coverage: Full spec implemented as of Licensing: Commercial, trial version available for download Contact Info: https://halon.io Implementation notes: GPL’d library with ARC capabilities: https://github.com/halon/libdkimpp

Organization: Internet Initiative Japan (IIJ) Status of Operation: Operational as of October 2018 Coverage: Full spec implemented as of &SELF; Licensing: Internal Contact Info: https://www.iij.ad.jp/en/ Implementation notes: Internal MTA implementation validated during the ARC interop exercise in mid-October 2018

&RFC2119; &RFC5234; &RFC5322; &RFC5598; &RFC6376; &RFC6377; &RFC6532; &RFC7208; &RFC7405; &RFC8174; &RFC7942; &RFC7489; &RFC7960;

The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.

Provide a verifiable “chain of custody” for email messages; Not require changes for originators of email; Support the verification of the ARC header field set by each hop in the handling chain; Work at Internet scale; and Provide a trustable mechanism for the communication of Authentication-Results across trust boundaries.

ARC is not a trust framework. Users of the ARC header fields are cautioned against making unsubstantiated conclusions when encountering a “broken” ARC sequence.

The following message is an example of one which has passed through several intermediary handlers, some of which have modified the message and others which have not:

Received: from example.org (example.org [208.69.40.157]) by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) Received: from mail-ob0-f188.google.example (mail-ob0-f188.google.example [208.69.40.157]) by clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s= clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7 +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d= clochette.example.org; h=message-id:date:from:to:subject; s= clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf K7ccBMP7Zjb/mpeggswHjEMS8x5NQ== ARC-Authentication-Results: i=3; clochette.example.org; spf=fail smtp.from=jqd@d1.example; dkim=fail (512-bit key) header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass, ams.2.gmail.example=pass, as.1.lists.example.org=pass, ams.1.lists.example.org=fail (message has been altered)) Authentication-Results: clochette.example.org; spf=fail smtp.from=jqd@d1.example; dkim=fail (512-bit key) header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass, ams.2.gmail.example=pass, as.1.lists.example.org=pass, ams.1.lists.example.org=fail (message has been altered)) ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t= 12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE 8jjLXWpRNuh81yqnT1/jHn086RwezGw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= gmail.example; h=message-id:date:from:to:subject; s=20120806; t= 12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44 cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5 9WSqI9s9DfyKDfWg== ARC-Authentication-Results: i=2; gmail.example; spf=fail smtp.from=jqd@d1.example; dkim=fail (512-bit key) header.i=@example.org; dmarc=fail; arc=pass (as.1.lists.example.org=pass, ams.1.lists.example.org=pass) ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists; t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/ lHxLi21pxu347isLSuNtvIagIvAQna9a5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= lists.example.org; h=message-id:date:from:to:subject; s= dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y yHgcIwGHhSc/4+ewYqHMWDnuFxiQ== ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key) header.i=@d1.example; dmarc=pass DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h= message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q 0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA== Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@dmarc.example Subject: [List 2] Example 1 Hey gang, This is a test message. --J. ]]>

This draft originated with the work of OAR-Dev Group. The authors thank all of the OAR-Dev and the subsequent DMARC-WG group for the ongoing help and though-provoking discussions from all the participants, especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen, Gene Shuman, Scott Kitterman, Bron Gondwana. Grateful appreciation is extended to the people who provided feedback through the discuss mailing list.

Please address all comments, discussions, and questions to dmarc@ietf.org. Earlier discussions can be found at arc-discuss@dmarc.org. Interop discussions planning can be found at arc-interop@dmarc.org. Some introductory material for less technical people can be found at https://arc-spec.org.