RFC 8617
The Authenticated Received Chain (ARC) Protocol
7. Use Cases
This section explores several message handling use cases that are addressed by ARC.7.1. Communicate Authentication Assessment across Trust Boundaries
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.
7.1.1. Message-Scanning Services
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. Rerouting 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.7.1.2. Multi-tier MTA Processing
A 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.7.1.3. Mailing Lists
Mailing lists take delivery of messages and repost them to subscribers. A full description of authentication-related mailing list issues can be found in [RFC7960], 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.
7.2. Inform Message Disposition Decisions
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: 1. identify ARC-enabled ADMDs that break authentication while processing messages and 2. 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.7.2.1. DMARC Local Policy Overrides
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 [RFC7960]. 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 Section 7.2.2.
7.2.2. DMARC Reporting
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 [RFC7489], Appendix C) containing a list of data discovered during ARC validation, which at a minimum includes: o the Chain Validation Status, o the domain and selector for each AS, and o the originating IP address from the first ARC Set. EXAMPLE: <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>fail</spf> <reason> <type>local_policy</type> <comment>arc=pass as[2].d=d2.example as[2].s=s2 as[1].d=d1.example as[1].s=s3 remote-ip[1]=2001:DB8::1A</comment> </reason> </policy_evaluated> In the example DMARC XML reporting fragment above, data relating to specific validated ARC Sets are enumerated using array syntax (e.g., "as[2]" means an AS header field with an 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 behavior and make the necessary accommodations.8. Privacy Considerations
The Authenticated Received Chain provides a verifiable record of the handlers for a message. This record may include personally identifiable information such as an IP address(es) and domain names. Such information is also included in existing non-ARC-related header fields such as the "Received" header fields.
9. Security Considerations
The Security Considerations of [RFC6376] and [RFC8601] apply directly to this specification. As with other domain-based authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the semantic content of messages. A received message with a validated ARC Chain provides evidence (at instance N) that: 1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body, 2. the authentication assessment reported in the ARC-Authentication- Results was determined upon receipt of the corresponding message at the sealing domain, and 3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.9.1. Increased Header Field Size
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.9.2. DNS Operations
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 that can increase the total number of queries). This leads to two considerations: 1. 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 a downstream validating ADMD infrastructure.
2. 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.
9.3. Message Content Suspicion
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.
9.4. Message Sealer Suspicion
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.
9.5. Replay Attacks
Since ARC inherits heavily from DKIM, it has similar attack vectors.
In particular, the replay attack described in [RFC6376], 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 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. The scope of this
attack can be limited by caching DNS queries and following the same
signing scope guidance from [RFC6376], Section 5.4.1.
10. IANA Considerations
This document defines one new authentication method and several status codes (Section 10.1), new ptypes and properties (Section 10.2), three new headers fields (Section 10.3), and a new enumerated status code (Section 10.4).10.1. Update to Email Authentication Result Names Registry
Per this document, IANA has added one authentication method with three codes to the IANA "Email Authentication Result Names" registry: o Auth Method: arc Code: "none", "pass", "fail" Specification: RFC 8617, Section 4.4 Status: active10.2. Update to Email Authentication Methods Registry
Per this document, IANA has added the following to the "Email Authentication Methods" registry, which is defined in [RFC8601]: o Method: arc Definition: RFC 8617, Section 6 ptype: smtp Property: remote-ip Value: IP address (v4 or v6) of originating SMTP connection Status: active Version: 1 o Method: arc Definition: RFC 8617, Section 6 ptype: header Property: oldest-pass Value: The instance id of the oldest validating AMS or 0 if they all pass (see Section 5.2) Status: active Version: 1
10.3. New Header Fields in Permanent Message Header Field Registry
Per this document, IANA has added the following three new header fields to the "Permanent Message Header Field Names" registry: o Header field name: ARC-Seal Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 6376 o Header field name: ARC-Message-Signature Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 6376 o Header field name: ARC-Authentication-Results Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 860110.4. New Status Code in Enumerated Status Codes Registry
Per this document, IANA has added the following value to the "Enumerated Status Codes" registry: o 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 ARC validation. Reference: RFC 8617 Submitter: K. Andersen Change controller: IESG
11. Experimental Considerations
The ARC protocol is designed to address common interoperability issues introduced by intermediate message handlers. Interoperability issues are described in [RFC6377] and [RFC7960]. 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.11.1. Success Consideration
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 achieved through the use of heuristic approaches.11.2. Failure Considerations
ARC should function without introducing significant new vectors for abuse (see Section 9). If unforeseen vectors are enabled by ARC, this protocol will be a failure. Note that the weaknesses inherent in the mail protocols ARC is built upon (such as DKIM replay attacks and other known issues) are not new vectors that can be attributed to this specification.11.3. Open Questions
The following open questions are academic and have no clear answer at the time this document was published. However, additional deployments should be able to gather the necessary data to answer some or all of them.11.3.1. Value of the ARC-Seal (AS) Header Field
Data should be collected to show if the AS provides value beyond the AMS for either making delivery decisions or catching malicious actors trying to craft or replay malicious chains.
11.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in ARC Sets
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.11.3.3. DNS Overhead
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 Section 9.2), it is unclear how much overhead will truly be added. This is similar to some of the initial processing and query load concerns that 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.11.3.4. What Trace Information Is Valuable?
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.12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/info/rfc8601>. [RFC8616] Levine, J., "Email Authentication for Internationalized Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, <https://www.rfc-editor.org/info/rfc8616>.12.2. Informative References
[ARC-MULTI] Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol", Work in Progress, draft-ietf- dmarc-arc-multi-03, March 2019. [ARC-USAGE] Jones, S., Ed. and K. Andersen, "Recommended Usage of the Authenticated Received Chain (ARC)", Work in Progress, draft-ietf-dmarc-arc-usage-07, April 2019. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, <https://www.rfc-editor.org/info/rfc7960>.
Appendix A. Design Requirements
The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.A.1. Primary Design Criteria
o Provide a verifiable "chain of custody" for email messages; o Not require changes for originators of email; o Support the verification of the ARC header field set by each hop in the handling chain; o Work at Internet scale; and o Provide a trustable mechanism for the communication of Authentication-Results across trust boundaries.A.2. Out of Scope
ARC is not a trust framework. Users of the ARC header fields are cautioned against making unsubstantiated conclusions when encountering a "broken" ARC sequence.
Appendix B. Example Usage
The following message is an example of one that has passed through several intermediary handlers, some of which have modified the message and others which have not: Return-Path: <jqd@d1.example> Received: from example.org (example.org [208.69.40.157]) by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207 for <fmartin@example.com>; 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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [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 <fmartin@example.org>; 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 <jqd@d1.example>
To: arc@dmarc.example
Subject: [List 2] Example 1
Hey gang,
This is a test message.
--J.
Acknowledgments
This document originated with the work of OAR-Dev Group. The authors thank all of the OAR-Dev and the subsequent DMARC WG for the ongoing help and thought-provoking discussions from all the participants, especially J. Trent Adams, Marc Bradshaw, Alex Brotman, Greg Colburn, Dave Crocker, Tim Draegen, Mark Eissler, Peter Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Scott Kitterman, Barry Leiba, Franck Martin, John Rae-Grant, Paul Rock, Gene Shuman, Terry Zink, and Elizabeth Zwicky. Grateful appreciation is extended to the people who provided feedback through the arc-discuss mailing list.Authors' Addresses
Kurt Andersen LinkedIn 1000 West Maude Ave Sunnyvale, California 94085 United States of America Email: kurt+ietf@drkurt.com Brandon Long (editor) Google Email: blong@google.com Seth Blank (editor) Valimail Email: seth@valimail.com Murray Kucherawy (editor) TDP Email: superuser@gmail.com