draft-ietf-dmarc-arc-protocol-06.txt   draft-ietf-dmarc-arc-protocol-07.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Standards Track B. Long, Ed. Intended status: Standards Track B. Long, Ed.
Expires: January 19, 2018 Google Expires: January 22, 2018 Google
S. Jones, Ed. S. Jones, Ed.
M. Kucherawy, Ed.
TDP TDP
July 18, 2017 July 21, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-06 draft-ietf-dmarc-arc-protocol-07
Abstract Abstract
Authenticated Received Chain (ARC) permits an organization which is The Authenticated Received Chain (ARC) protocol creates a mechanism
creating or handling email to indicate its involvement with the whereby a series of handlers of a message can conduct authentication
handling process. It defines a set of cryptographically signed of a message as it passes among them on the way to its destination,
header fields in a manner analagous to that of DKIM. Assertion of and record the status of that authentication at each step along the
responsibility is validated through a cryptographic signature and by handling path, for use by the final recipient in making choices about
querying the Signer's domain directly to retrieve the appropriate the disposition of the message.
public key. Changes in the message that might break DKIM can be
identified through the ARC set of header fields.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2018. This Internet-Draft will expire on January 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4
2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5
5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6
5.1. Description of the New Header Fields . . . . . . . . . . 6 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6
5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6
5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 10 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7
5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 11 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 12 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Handling Minor Violations in the ARC Sets . . . . . . 13 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 8
5.2.2. Handling Major Violations in the ARC Sets . . . . . . 13 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Key Management and Binding . . . . . . . . . . . . . . . 14 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 14 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Supporting Alternate Signing Algorithms . . . . . . . . . 14 9. Usage of Chain Validity . . . . . . . . . . . . . . . . . . . 11
5.4.1. Introductory Period . . . . . . . . . . . . . . . . . 14 9.1. Assessing Chain Validity Violations . . . . . . . . . . . 11
5.4.2. Co-Existence Period . . . . . . . . . . . . . . . . . 14 9.2. Marking and Sealing Invalid Chains . . . . . . . . . . . 11
5.4.3. Deprecation Period . . . . . . . . . . . . . . . . . 14 9.3. Handling DNS Problems While Validating ARC . . . . . . . 12
5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 15 9.4. Responding to ARC Validity Violations . . . . . . . . . . 12
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.5. Recording the Results of ARC Evaluation . . . . . . . . . 12
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 15 9.5.1. Output Information from an ARC Evaluation . . . . . . 12
6.2. Relationship between DKIM Signatures and ARC Headers . . 15 9.5.2. Reporting ARC Effects for DMARC Local Policy -
6.3. Validating the ARC Set of Header Fields . . . . . . . . . 15 Interim . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 15 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 13
6.4.1. Assessing Chain Validity Violations . . . . . . . . . 15 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 14
6.4.2. Marking and Sealing Invalid Chains . . . . . . . . . 16 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 14
6.4.3. Responding to ARC Validity Violations . . . . . . . . 16 10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 14
6.4.4. Recording the Results of ARC Evaluation . . . . . . . 16 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6.4.5. Output Data Points from ARC Evaluation . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.4.6. Reporting ARC Effects for DMARC Local Policy - 12.1. Authentication-Results Method Registry Update . . . . . 14
Interim . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. Definitions of the ARC header fields . . . . . . . . . . 15
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13.1. GMail test reflector and incoming validation . . . . . . 16
8.1. Authentication-Results Method Registry Update . . . . . . 17 13.2. AOL test reflector and internal tagging . . . . . . . . 16
8.2. Definitions of the ARC header fields . . . . . . . . . . 18 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. GMail test reflector and incoming validation . . . . . . 19 13.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 18
9.2. AOL test reflector and internal tagging . . . . . . . . . 20 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 18
9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.8. PERL Mail::Milter::Authentication module . . . . . . . . 19
9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21
9.6. Copernica/MailerQ web-based validation . . . . . . . . . 22 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 25
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Appendix A - Example Usage (Obsolete but retained Appendix A. Appendix A - Example Usage (Obsolete but retained
for illustrative purposes) . . . . . . . . . . . . . 26 for illustrative purposes) . . . . . . . . . . . . . 23
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 26 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 23
A.1.1. Here's the message as it exits the Origin: . . . . . 26 A.1.1. Here's the message as it exits the Origin: . . . . . 23
A.1.2. Message is then received at example.org . . . . . . . 27 A.1.2. Message is then received at example.org . . . . . . . 24
A.1.3. Example 1: Message received by Recipient . . . . . . 29 A.1.3. Example 1: Message received by Recipient . . . . . . 26
A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 30 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 27
A.2.1. Here's the message as it exits the Origin: . . . . . 30 A.2.1. Here's the message as it exits the Origin: . . . . . 27
A.2.2. Message is then received at example.org . . . . . . . 31 A.2.2. Message is then received at example.org . . . . . . . 28
A.2.3. Example 2: Message received by Recipient . . . . . . 35 A.2.3. Example 2: Message received by Recipient . . . . . . 32
A.3. Example 3: Mailing list to forwarded mailbox with source 37 A.3. Example 3: Mailing list to forwarded mailbox with source 34
A.3.1. Here's the message as it exits the Origin: . . . . . 37 A.3.1. Here's the message as it exits the Origin: . . . . . 34
A.3.2. Message is then received at example.org . . . . . . . 38 A.3.2. Message is then received at example.org . . . . . . . 35
A.3.3. Example 3: Message received by Recipient . . . . . . 43 A.3.3. Example 3: Message received by Recipient . . . . . . 40
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 45 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 46 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The development of strong domain authentication through Sender Policy Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] has led to the implementation of the DMARC framework [RFC6376] have become ubiquitious. However, they are stymied by a
[RFC7489] which extends the authentication to the author's "From:" small number of common applications, most notably mailing list
(RFC5322.From) field and permits publishing policies for non- managers, as these applications have handling properties that prevent
compliant messages. Implicit within the DMARC framework is a these authentication schemes from universal effectiveness. These
requirement that any intermediaries between the source system and issues are described in substantial detail in those protocols'
ultimate receiver system need to preserve the validity of the DKIM defining documents as well as in [RFC6377].
signature; however, there are common legitimate email practices which
break the DKIM validation ([RFC7960]). This specification defines an
Authenticated Received Chain (ARC). ARC addresses the problems with
the untrustworthiness of the standard Received header field sequence.
Through the information tracked in the ARC series of headers,
receivers can develop a more nuanced interpretation to guide any
local policies related to messages that arrive with broken domain
authentication (DMARC).
Forgery of the Received header fields is a common tactic used by bad
actors. One of the goals of this specification defines a comparable
set of trace header fields which can be relied upon by receivers,
assuming all ADministrative Management Domain (ADMD) ([RFC5598],
section 2.2) intermediary handlers of a message participate in ARC.
The Authentication-Results (A-R) mechanism [RFC7601] permits the In an effort to reduce the success of fraudulent email campaigns,
output of an email authentication evaluation process to be there has been an effort to develop and deploy technologies that use
transmitted from the evaluating agent to a consuming agent that uses SPF and DKIM to assure legitimate use of the identity of the apparent
the information. On its own, A-R is believable only within a trust message author, i.e., the visible "From:" field in a message. To
domain. ARC provides a protection mechanism for the data, permiting this end, Domain-based Mail Authentication, Reporting and Compliance
the communication to cross trust domain boundaries. (DMARC) [RFC7489] has been developed and deployed. However, its
deployment in environments where mailing lists are used has had the
negative impacts predicted in the documents listed above.
2. Requirements What is needed is a mechanism by which legitimate alteration of a
message, invalidating SPF and DKIM, does not ultimately result in a
rejection of an email message on delivery. An Authenticated Received
Chain (ARC), described here, provides a superset of the functionality
of DKIM in order to provide to the final message recipient a more
complete view into the handling chain of a message and the points in
that chain where alterations of the content may have occurred.
Equipped with this more compelte information, the final recipient can
make a more informed handling choice, reducing or eliminating the
false postives inherent in use of DKIM and/or SPF themselves.
The specification of the ARC framework is driven by the following 2. Overview
high-level goals, security considerations, and practical operational
requirements.
2.1. Primary Design Criteria In DKIM, every participating signing agent attaches a signature that
is based on the content of the message, local policy, and the domain
name of the participating Administrative Management Domain (ADMD).
Any verifier can process such a signature; a verified signature means
the message content that was "covered" by the signature has not been
altered since the signature was applied. The signatures themselves
are generally independent of one another.
o Provide a verifiable "chain of custody" for email messages; By contrast, this protocol seeks to have each signature be able to
convey the following pieces of information:
o Not require changes for originators of email; 1. As with DKIM, an assertion that, for a passing signature, the
domain name in the signature takes some responsibility for
handling of the message and that the message is unchanged since
that signature was applied;
o Support the verification of the ARC header field set by each hop 2. A further assertion that, at the time that same ADMD processed
in the handling chain; the message, the various assertions already attached to the
message by other ADMDs were or were not valid;
o Work at Internet scale; and 3. A further assertion that combines and protects the above against
alteration by later handlers.
o Provide a trustable mechanism for the communication of This protocol accomplishes each of these by adding a new header field
Authentication-Results across trust boundaries. to the message for each of them, as follows:
2.2. Out of Scope o ARC-Authentication-Results: (referred to below as "AAR") virtually
identical in syntax to an Authentication-Results field [RFC7601],
this field records the results of all message authentication
checks done by the recording ADMD at the time the message arrived;
ARC is not a trust framework. Users of the ARC header fields are o ARC-Message-Signature: (referred to below as "AMS") virtually
cautioned against making unsubstantiated conclusions when identical in syntax to DKIM-Signature, this field contains the
encountering a "broken" ARC sequence. assertions about the message header and body as they existed at
the time of handling by the ADMD adding it; and
2.3. Utility o ARC-Seal: (referred to below as "AS") highly similar in structure
and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of these
fields added by prior ADMDs.
The ARC-related set of header fields can be used (when validated) to A distinguishing feature of all of these is that an ARC participant
determine the path that an email message has taken between the always adds all of them before relaying a message to the next
originating system and receiver. Subject to the cautions mentioned handling agent en route to its destination. Moreover, as described
in Section 10, this information can assist in determining any local in Section 4, they each have an "instance" number that increases with
policy overrides to for violations of origination domain each ADMD in the handling chain so that their original order can be
authentication policies. preserved and the three of them can be processed as a group.
3. Terminology 3. Terminology
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are encouraged to be familiar with the contents of [RFC5598], Readers are encouraged to be familiar with the contents of [RFC5598],
and in particular, the potential roles of intermediaries in the and in particular, the potential roles of intermediaries in the
delivery of email. delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
4. Overview A single group of the header fields introduced in Section 2 is called
an "ARC Set", and the complete sequence of these groups is called an
When an email message is received without a properly validated "Authenticated Received Chain" or merely an "ARC chain". Although
originating domain, the inability to believe the accuracy of a series the "Received" header field is typically not included in the signed
of Received header fields prevents receiving systems from having a content, the name is based on the notion that this is in essence a
way to infer anything about the handling of the message by looking at cryptographically signed series of header fields that attest to the
the ADMDs through which the message has traveled. handling chain of a message much as Received fields always have.
With ARC, participating ADMDs are able to securely register their
handling of an email message. If all mediators ([RFC5598])
participate in the ARC process, receivers will be able to rely upon
the chain and make local policy decisions informed by that
information.
The ARC set of header fields provides a method by which participating
intermediaries can indicate the hand-offs for email messages.
5. Definition
This specification defines three new header fields:
o Header field name: ARC-Seal (abbreviated below as AS)
o Header field name: ARC-Message-Signature (abbreviated below as
AMS)
o Header field name: ARC-Authentication-Results (abbreviated below
as AAR)
Collectively, these header fields form a connected set of attribution
information by which receivers can identify the handling path for a
message. As described below, a distinct set of these fields share a
common sequence number, identified in an "i=" tag. Such a correlated
group of header fields is referred to as an "ARC set".
Specific references to individual header fields use the header field
names to distinguish such references.
The ARC sets SHOULD be added at the top of a message header as it
transits MTAs that do authentication checks, so some idea of how far
away the checks were done can be inferred. They are therefore
considered to be a trace field as defined in [RFC5321], and all of
the related definitions in that document apply.
Relative ordering of different trace header fields (the ARC sets,
DKIM, Received, etc.) is unimportant for this specification. In
general, trace header fields, such as ARC, SHOULD be added at the top
of the email header fields, but receivers MUST be able to process the
header fields from wherever they are found in the message header.
Ordering amongst the individual ARC header fields and sets is
specified below and MUST be followed for proper canonicalized signing
and evaluation.
5.1. Description of the New Header Fields
5.1.1. ARC-Seal
ARC-Seal is a Structured Header Field as defined in Internet Message
Format ([RFC5322]). All of the related definitions in that document
apply.
The ARC-Seal makes use of Tag=Value Lists as defined in [RFC6376],
Section 3.2.
The value of the header field consists of an authentication sequence
identifier, and a series of statements and supporting data. The
statements indicate relevant data about the signing of the ARC set.
The header field can appear more than once in a single message, but
each instance MUST have a unique "i=" value.
The ARC-Seal header field includes a digital signature of all
preceding ARC message header fields on the message.
5.1.1.1. Tags in the ARC-Seal Header Field Value
The following tags are the only supported tags for an ARC-Seal field.
All of them MUST be present. Unknown tags MUST be ignored and do not
affect the validity of the header.
o a = hash algorithm; syntax is the same as the "a=" tag defined in
Section 3.5 of [RFC6376];
o b = digital signature; syntax is the same as the "b=" tag defined
in Section 3.5 of [RFC6376];
o cv = chain validation status: valid values:
* 'none' = no pre-existing chain;
* 'fail' = the chain as received does not or can not validate; or
* 'pass' = valid chain received.
o d = domain for key; syntax is the same as the "d=" tag defined in
Section 3.5 of [RFC6376];
o i = "instance" or sequence number; monotonically increasing at 4. Instance ('i=') Tags
each "sealing" entity, beginning with '1', see Section 5.1.1.1.1
regarding the valid range
o s = selector for key; syntax is the same as the "s=" tag defined The header fields comprising a single ARC set are identified by the
in Section 3.5 of [RFC6376]; presence of a string in the value portion of the header field that
complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
The tag-name is always the single character "i" and the value is the
text representation of a positive integer, indicating the position in
the ARC sequence this set occupies, where the first ARC set is
numbered 1. In ABNF terms:
o t = timestamp; syntax is the same as the "t=" tag defined in instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"
Section 3.5 of [RFC6376].
5.1.1.1.1. Valid Range for "Instance" 'i' Tag Value At any delivery stage, it is an error if any ARC set is invalid
(i.e., does not contain exactly one of the three header fields
defined by this protocol).
5.1.1.1.1.1. Minimum 'i' Tag Value Note that because the AMS and AS header field values are made up of
tag-spec constructs, the i= tag may be found anywhere within the
header field value, but is represented throughout this spec in the
initial position for convenience. Implementers SHOULD seek to start
with the i= tag to facilitate human inspection of the headers.
The minimum valid 'i' tag value is one (1). 4.1. Valid Range for Instance Tags
5.1.1.1.1.2. Maximum 'i' Tag Value The 'i' tag value can range from 1-1024 (inclusive).
ARC implementations MUST support at least ten (10) intermediary ARC implementations MUST support at least ten (10) intermediary
steps. steps.
More than fifty (50) intermediaries is considered extremely unlikely More than fifty (50) intermediaries is considered extremely unlikely
so ARC chains with more than fifty intermediaries may be marked with so ARC chains with more than fifty intermediaries may be marked with
"cv=fail". "cv=fail".
The maximum valid 'i' tag value is 1024, but values more that the 5. The ARC Header Fields
supported number of intermediaries are meaningless.
5.1.1.2. Differences between DKIM-Signature and ARC-Seal
No 'bh' value is defined for ARC-Seal, since only message header
fields are ever signed by the ARC-Seal.
ARC-Seal does not use the 'h' tag (the list of signed header fields)
that is defined for DKIM-Signatures because the list of applicable
header fields is fully determined by the construction rules (see
Section 5.1.1.3).
ARC-Seal does not use the 'c' (canonicalization) tag because only
'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header
field canonicalization.
5.1.1.3. Deterministic (Implicit) 'h' Tag Value for ARC-Seal
In this section, the term "scope" is used to indicate those header
fields signed by an ARC-Seal header field. A number in parentheses
indicates the instance of that field, starting at 1. The suffix "-
no-b" is used with an ARC-Seal field to indicate that its "b" field
is empty at the time the signature is computed, as described in
Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication-
Results, "AMS" to ARC-Message-Signature, "AS" to ARC-Seal, and "ASB"
to an ARC-Seal with an empty "b" tag.
Generally, the scope of an ARC set for a message containing "n" ARC
sets is the concatenation of the following, for x (instance number)
from 1 to n:
o AAR(x);
o AMS(x);
o ASB(x) if x = n, else AS(x)
Thus for a message with no seals (i.e., upon injection), the scope of
the first ARC set is AAR(1):AMS(1):ASB(1). The ARC set thus
generated would produce a first ARC-Seal with a "b" value. The next
ARC set would include in its signed content the prior scope, so it
would have a scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2).
Note: Typically header field sets appear within the header in
descending instance order.
5.1.1.4. Computing the 'b' Tag Value for ARC-Seal
The ARC-Seal generation process mirrors the procedure used for DKIM-
Signature fields described in Section 5 of [RFC6376] in that it is at
first generated with empty "b" field for the purpose of signature
generation, and then the "b" value is added just prior to adding the
ARC-Seal field to the message.
In particular, signing calculation MUST be done in bottom-up order as
specified in Section 5.4.2 of [RFC6376] and as illustrated above
Section 5.1.1.3.
5.1.1.5. Determining the 'cv' Tag Value for ARC-Seal
In order for a series of ARC sets to be considered valid, the
following statements MUST be satisfied:
1. The chain of ARC sets must have structural integrity (no sets or
set component header fields missing, no duplicates, excessive
hops (cf. Section 5.1.1.1.1), etc.);
2. All ARC-Seal header fields MUST validate;
3. All ARC-Seal header fields MUST have a chain value (cv=) status
of "pass" (except the first which MUST be "none"); and
4. The newest (highest instance number (i=)) AMS header field MUST
validate.
5.1.1.5.1. Pseudocode to Determine Chain Value Status:
In the algorith below, a "hop" is represented by the ARC set bearing
a particular instance number. The number of hops is the same as the
highest instance number found in the ARC sets, or 0 (zero) if there
are no ARC sets found within the header.
"Success" means that the signature found in the referenced header
validates when checked against the specified content.
if (lastest_hop.AS.cv == "fail") {
terminate analysis - no further ARC processing
}
if (chain not structurally valid) {
return "fail"
} else if (num_hops == 0) {
return "none"
} else {
if (validate(latest_hop.AMS) != success) {
return "fail"
} else {
// note that instance is always >= 1 by definition
for each hop (from highest instance to lowest) {
if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or
(hop_num == 1 and hop.ARC-Seal.cv == "none")) {
if (validate(hop.ARC-Seal) != success) {
return "fail"
}
} else {
return "fail"
}
}
}
return "pass"
}
5.1.2. ARC-Message-Signature
The ARC-Message-Signature header field is a special variant of a
DKIM-Signature [RFC6376].
The ARC-Message-Signature header field can appear multiple times in a The three header fields that are part of this specification borrow
single message but each instance MUST have a unique "i=" value. heavily from existing specifications. Rather than repeating all of
the formal definitions that are being recycled in ARC, this document
instead only describes and specifies changes in syntax and semantics.
5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature 5.1. ARC-Authentication-Results (AAR)
5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion The ARC-Authentication-Results header field is defined. It is
syntactically and semantically identical to an Authentication-Results
header field [RFC7601] (A-R), as is the mechanism by which it is
constructed, with the following exception:
Participants may include any other header fields within the scope of o There is an "i" tag, as described in Section 4.
the ARC-Message-Signature signature except that they MUST NOT include
ARC-Seal headers fields. In particular, including all DKIM-Signature
header fields and all ARC-Authentication-Results header fields is
RECOMMENDED. The advice regarding headers to include or avoid for
ARC-Message-Signature is otherwise identical to that specified in
section 5.4 of [RFC6376].
5.1.2.1.2. "Canonicalization" 'c' Tag Value The instance identifier MUST be separated from the rest of the
Authentication-Results value contents with a semi-colon (';', 0x3b).
The ARC-Message-Signature header field MUST be created using the An ARC signer generates this field in the same way that a
header and body canonicalization rules mechanisms in Section 3.4 of conventional A-R field would be generated. Because the AAR is
[RFC6376]. The corresponding "c=" tag value MUST be specified in the designed for machine-based consumption over the course of a message's
AMS header field value. transit through a series of mediators and to facilitate
troubleshooting of problematic sources by sending organizations, two
additional fields of data SHOULD be added to the normal A-R content,
if available to the A-R generating system:
5.1.2.1.3. "Instance" 'i' Tag Value o source.ip - The connecting client IP address from which the
message is received; and
Contrary to DKIM, the 'i' tag for ARC-Message-Signature identifies o header.s - The selector value associated with each dkim signature
the sequential instance of the field, thus indicating that it is part (added to the dkim or arc data sections of the A-R/AAR record
of a particular ARC set. That is, an ARC-Message-Signature, ARC-
Seal, and ARC-Authentication-Results all bearing an "i=" tag with the
same value are part of the same ARC set (see Section 5.1.1.1).
5.1.2.1.4. 'v' Tag Value The purpose of this header field is to incorporate into the record
the success or failure of any authentication done on the message
upstream of the participating ADMD, to validate and continue the
authentication chain.
There is no "v" tag for ARC-Message-Signature. In processing, some architectures will generate multiple A-R records
for the same authserv-id. In such cases, the resinfo value from each
of the A-R records should be concatenated into a single record just
as they would have been if they were generated in a single A-R
record.
5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature 5.2. ARC-Message-Signature (AMS)
As with DKIM-Signature and ARC-Seal header fields, the "b" tag of the The ARC-Message-Signature header field is defined. It is
ARC-Message-Signature is empty until the signature is actually syntactically and semantically identical to a DKIM-Signature header
computed, and only then is it added to the header field, before field [RFC6376], as is the mechanism by which it is constructed, with
affixing the ARC-Message-Signature to the message. the following exceptions:
As with ARC-Seal and DKIM-Signature header fields, the order of o There is an "i" tag, as described in Section 4.
header fields signed MUST be done in bottom-up order.
5.1.3. ARC-Authentication-Results o There is no "v" tag.
[[ Note: The intent of the AAR header is to provide the necessary o ARC-Seal header fields MUST never be included in the content
information for meaningful DMARC reporting back to the originating covered by the signature in this header field.
ADMD. As such, it needs to include additional information than the
user-focused Authentication-Results header [RFC7601] but the details
of that incremental information have not yet been fully determined.
]]
ARC-Authentication-Results is a copy of the Authentication-Results The AMS SHOULD include any DKIM-Signature header fields already
header field [RFC7601] value with the corresponding ARC-set instance present on the message in the header fields covered by this
("i=") tag value prefixed to the Authentication-Results value string. signature.
Since Authentication-Results headers are frequently deleted from a
message's header list, the AAR is created for archival purposes by
each ARC-participating ADMD outside of the trust boundary of the
originating system.
The instance identifier MUST be separated from the rest of the Authentication-Results header fields SHOULD NOT be included since
Authentication-Results value contents with a semi-colon (';', 0x3b). they are likely to be deleted by downstream ADMDs, thereby breaking
the AMS signature.
The value of the header field (after removing comments) consists of As with a DKIM-Signature, the purpose of this header field is to
an instance identifier, an authentication identifier, and then a allow the ADMD generating it to take some responsibility for handling
series of statements and supporting data, as described in [RFC7601]. this message as it progresses toward delivery.
The header field can appear multiple times in a single message but
each instance MUST have a unique "i=" value.
5.1.3.1. 'i' Tag Value 5.3. ARC-Seal (AS)
ARC-Authentication-Results requires inclusion of an "i=" tag before The ARC-Seal header field is defined. It is syntactically and
the "authserv-id" which indicates the ARC set to which it belongs as semantically similar to a DKIM-Signature field, with the following
described in the previous section (see Section 5.1.1.1). exceptions:
The "i=" tag MUST be separated from the rest of the Authentication- o There is an "i" tag, as described in Section 4.
Results value contents with a semi-colon (';', 0x3b).
5.2. Constructing the ARC-Seal Set o The ARC-Seal covers none of the body content of the message. It
only covers specific header fields. (See below: Section 5.3.2.)
As a result, no body canonicalization is done. Further, only
"relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
used.
The ARC-Seal is built in the same fashion as the analogous DKIM- o The only supported tags are "i" (Section 4 supercedes the
Signature [RFC6376], using the relaxed header canonicalization rules [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
specified in that document but with a strict ordering component for tag definitions are copied from Section 3.5 of [RFC6376].
the header fields covered by the cryptographic signature:
1. The ARC sets MUST be ordered in descending instance (i=) order. o An additional tag, "cv" is defined. (See below: Section 5.3.1)
2. The referenced ARC-Message-Signatures (matching i= value) MUST The purpose of this field is to assure the integrity of the ARC set
immediately follow the ARC-Seal instance which included the being added by the ADMD generating this header field, and moreover to
reference. ensure no tampering with the ARC overall.
3. The associated ARC-Authentication-Results header field (matching 5.3.1. The 'cv' Tag
i= value) MUST be the last item in the list for each set of ARC
header fields.
Thus, when prefixing ARC header fields to the existing header, A new tag "cv" (chain validation) is defined, which indicates the
state of the ARC chain as evaluated when it arrived at the ADMD
adding this header field. It includes one of three possible values:
1. the AAR header would be prefixed first; then o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
any upstream MTAs may not be participating in ARC handling;
2. the AMS would be calculated and prefixed (above the AAR); o fail: The message has a chain whose validation failed;
3. lastly the AS would be calculated and prefixed (above the AMS). o pass: The message has a chain whose validation succeeded.
The ARC-Message-Signature field(s) MUST not include any of the ARC- In ABNF terms:
Seal header field(s) (from prior ARC sets) in their signing scope in
order maintain a separation of responsibilities. When adding an ARC-
Authentication-Results header field, it MUST be added before
computing the ARC-Message-Signature. When "sealing" the message, an
operator MUST create and attach the ARC-Message-Signature before the
ARC-Seal in order to reference it and embed the ARC-Message-Signature
within the ARC-Seal signature scope.
Each ARC-Seal is connected to its respective ARC-Message-Signature seal-cv-tag = %x63.76 [FWS] "=" [FWS]
and ARC-Authentication-Results through the common value of the "i=" ("none" / "fail" / "pass")
tag.
5.2.1. Handling Minor Violations in the ARC Sets 5.3.2. Selected Header Fields
When ordering the ARC header field sets, misordering of header fields The ARC-Seal signature is an encryption of the hash of the
MUST be resolved as follows: concatenation of the canonicalized form of the ARC sets present on
the message at the time of sealing, in increasing instance order,
starting at 1, including the one being added at the time of sealing
the message.
o Within each set, header fields are sorted as specified in Within a set, the header fields are presented in the following order:
Section 5.2; then
o Any remaining order dependencies between sets (e.g., such as 1. ARC-Authentication-Results
different hash algorithms) MUST be ordered as follows: 2. ARC-Message-Signature
1. (First) By descending order of i=; then 3. ARC-Seal
2. (Second) By descending order of t= (from the ARC-Seal header Where the ARC-Seal is the one being generated, it is presented to the
field within the set); then hash function in its final form except with an empty "b=" value, in
the same manner by which a DKIM-Signature signs itself.
3. (Finally) By ascending US-ASCII [RFC1345] sort order for the 6. Verifier Actions
entire canonicalized header field set
The intent of specifying this ordering is to allow downstream message The verifier takes the following steps to determine the current state
handlers to add their own ARC sets in a deterministic manner and to of the ARC on the message:
provide some resiliance against downstream MTAs which may reorder
header fields.
5.2.2. Handling Major Violations in the ARC Sets 1. Collect all ARC sets currently on the message. If there were
none, the ARC state is "none" and the algorithm stops here.
Gross violations of the ARC protocol definition (e.g., such as 2. If any ARC set is invalid (e.g., does not contain exactly one of
duplicated instance numbers or missing header fields or header field each of the three ARC-specific header fields), then the chain
sets) MUST be terminated by the detecting system setting 'cv=fail' in state is "fail" and the algorithm stops here.
the ARC-Seal header. The status of the ARC evaluation reported in
the corresponding AAR header field MUST be 'unknown'.
Because the violations can not be readily enumerated, the header 3. Conduct verification of the ARC-Message-Signature header field
fields signed by the AS header field in the case of a major violation bearing the highest instance number. If this verification fails,
MUST be only the matching 'i=' instance headers created by the MTA then the chain state is "fail" and the algorithm stops here.
which detected the malformed chain, as if this newest ARC set was the
only set present.
Downstream MTAs SHOULD NOT attempt any analysis on an ARC chain that 4. For each ARC-Seal from the "N"th instance to the first, apply the
has been marked 'fail'. following logic:
5.3. Key Management and Binding 1. If the value of the "cv" tag on that seal is "fail", the
chain state is "fail" and the algorithm stops here.
The public keys for ARC header fields follow the same requirements 2. If the instance number being processed is greater than 1 and
and semantics as those for DKIM-Signatures, described in Section 3.6 the value of the "cv" tag is "none", the chain state is
of [RFC6376]. Operators may use distinct selectors for the ARC "fail" and the algorithm stops here.
header fields at their own discretion.
5.3.1. Namespace 3. If the instance number being processed is 1 and the value of
the "cv" tag is not "none", the chain state is "fail" and the
algorithm stops here.
All ARC-related keys are stored in the same namespace as DKIM keys 4. Prepare a hash function corresponding to the "a" tag of the
[RFC6376]: "_domainkey" specifically by adding the "._domainkey" ARC-Seal.
suffix to the name of the key (the "selector"). For example, given
an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of
"example.com" and an "s=" value of "foo.bar", the DNS query seeking
the public key will a query at the name
"foo.bar._domainkey.example.com".
5.4. Supporting Alternate Signing Algorithms 5. Compute the canonicalized form of the ARC header fields, in
the order described in Section 5.3.2, using the "relaxed"
header canonicalization defined in (Section 3.4.2 of
[RFC6376]. Pass them to the hash function.
In the following branch diagrams, each algorithm is represented by an 6. Retrieve the final digest from the hash function.
'A' or 'B' at each hop to depict the ARC chain that develops over a
five hop scenario. 'x' represents a hop that does not support that
algorithm.
5.4.1. Introductory Period 7. Retrieve the public key identified by the "s" and "d" tags in
the ARC-Seal, as described in Section 8.
Intermediaries MUST be able to validate ARC chains build with either 8. Determine whether the signature portion ("b" tag) of the ARC-
algorithm but MAY create ARC sets with either (or both) algorithm. Seal and the digest computed above are valid according to the
public key.
The introductory period should be at least six (6) months. 9. If the signature is not valid, the chain state is "fail" and
the algorithm stops here.
5.4.2. Co-Existence Period 5. If all seals pass validation, then the chain state is "pass", and
the algorithm is complete.
Intermediaries MUST be able to validate ARC chains build with either The verifier should record the cv state for subsequent use by any
algorithm and MUST create ARC sets with both algorithms. Chains sealing which may be done later (potentially after message
ending with either algorithm may be used for the result. modification) within the same trust boundary. The cv state may be
recorded by sealing at the time of verification in an additional ARC
set or may be recorded out of band depending on the architecture of
the ADMD.
5.4.3. Deprecation Period 7. Signer Actions
ARC sets built with algorithms that are being deprecated MAY be This section includes a walk-through of the actions an ARC signing
considered valid within an ARC chain, however, intermediaries MUST implementation takes when presented with a message.
not create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years. The signing agent should undertake the following steps:
5.4.4. Obsolescence Period 1. Do any authentication steps that the ADMD normally does:
ARC sets which are created with obsolete algorithms must be ignored. 1. If a message is traveling within the same trust boundary,
this would include any transitive trust conveyance with the
message;
6. Usage 2. If a message is coming from outside the same trust boundary,
this would include any SPF / DKIM / DMARC / other
authentication evaluation steps.
For a more thorough treatment of the recommended usage of the ARC 2. Do any DKIM signing or authentication assertion steps that the
header fields for both intermediaries and end receivers, please ADMD normally does.
consult [ARC-USAGE].
6.1. Participation 3. Generate and optionally attach to the message an Authentication-
Results header field using the ADMD's authserv-id (see
Section 2.5 of [RFC7601]) indicating whatever authentication
might have been done by the MTA, or possibly indicate that none
was done.
The inclusion of additional ARC sets is to be done whenever a trust 1. If an ARC chain exists on the message, then set "N" equal to
boundary is crossed, and especially when prior DKIM-Signatures might the highest instance number found on the chain (i=);
not survive the handling being performed such as some mailing lists otherwise set "N" equal to zero for the following steps.
that modify the content of messages or some gateway transformations.
Note that trust boundaries might or might not exactly correspond with
ADMD boundaries. Some organizations may have internal trust
boundaries within a single ADMD or have trust boundaries which span
more than one ADMD.
Each participating ADMD MUST validate the preceding ARC set as a part 4. Generate and attach to the message an ARC-Authentication-Results
of asserting their own seal. Until the chain is determined to be header field using instance number N+1 and the same content from
failed, and marked with an ARC set bearing the "cv=fail" indication, the previous step.
each participating ADMD SHOULD apply their own seal.
6.2. Relationship between DKIM Signatures and ARC Headers 5. Generate and attach to the message an ARC-Message-Signature
header field using the general algorithm described in Section 5
of [RFC6376] and as modified in Section 5.1 above, using instance
number N+1.
ARC-aware DKIM signers do not DKIM-sign any ARC header fields. 6. Generate and attach to the message an ARC-Seal header field using
the general algorithm described in Section 5.3 above, using a
chain validation status as determined in Section 6 and instance
number N+1.
6.3. Validating the ARC Set of Header Fields 8. Key Management
Determining the validity of a chain of ARC sets is defined above in The public keys for ARC header fields follow the same requirements,
Section 5.1.1.5. Validation failures MUST be indicated with a "cv=" syntax and semantics as those for DKIM signatures, described in
tag value of 'fail' when attaching a subsequent ARC-Seal header Section 3.6 of [RFC6376]. Operators may use distinct selectors and/
field. or domains for the ARC header fields at their own discretion.
6.4. ARC Set Validity 9. Usage of Chain Validity
6.4.1. Assessing Chain Validity Violations 9.1. Assessing Chain Validity Violations
There are a wide variety of ways in which the ARC set of header There are a wide variety of ways in which the ARC set of header
fields can be broken. Receivers need to be wary of ascribing motive fields can be broken. Receivers need to be wary of ascribing motive
to such breakage although patterns of common behaviour may provide to such breakage although patterns of common behaviour may provide
some basis for adjusting local policy decisions. some basis for adjusting local policy decisions.
This specification is exclusively focused on well-behaved, This specification is exclusively focused on well-behaved,
participating intermediaries that result in a valid chain of ARC- participating intermediaries that result in a valid chain of ARC-
related header fields. The value of such a well-formed, valid chain related header fields. The value of such a well-formed, valid chain
needs to be interpreted with care since malicious content can be needs to be interpreted with care since malicious content can be
easily introduced by otherwise well-intended senders through machine easily introduced by otherwise well-intended senders through machine
or account compromises. All normal content-based analysis still or account compromises. All normal content-based analysis still
needs to be performed on any messages bearing a valid chain of ARC needs to be performed on any messages bearing a valid chain of ARC
header sets. header sets.
6.4.2. Marking and Sealing Invalid Chains 9.2. Marking and Sealing Invalid Chains
The header fields signed by the AS header field b= value in the case The header fields signed by the AS header field b= value in the case
of a major violation MUST be only the matching 'i=' instance headers of a major violation MUST be only the matching 'i=' instance headers
created by the MTA which detected the malformed chain, as if this created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present. (This is the same procedure newest ARC set was the only set present. (This is the same procedure
required for handling major/structural validity problems.) required for handling major/structural validity problems.)
6.4.3. Responding to ARC Validity Violations 9.3. Handling DNS Problems While Validating ARC
DNS failures to resolve or return data which is needed for ARC
validation SHOULD result in a 421 tempfail during the SMTP
conversation with the sending system. Temporary or intermittent DNS
problems will generally not be sufficiently transitory to allow a
mediator to obtain a different result during the ordinary transit
duration so it is better to have the source system queue the
problematic message(s) than to generate (potential) backscatter.
DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a cv=fail verdict.
9.4. Responding to ARC Validity Violations
If a receiver determines that the ARC chain has failed, the receiver If a receiver determines that the ARC chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7 MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code. corresponding SMTP response code.
6.4.4. Recording the Results of ARC Evaluation 9.5. Recording the Results of ARC Evaluation
Receivers MAY add an "arc=pass" or "arc=fail" method annotation into Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field. a locally-affixed Authentication-Results [RFC7601] header field along
with any salient comment(s).
6.4.5. Output Data Points from ARC Evaluation 9.5.1. Output Information from an ARC Evaluation
The evaluation of a series of ARC sets results in the following data The evaluation of a series of ARC sets results in the following data
which MAY be used to inform local-policy decisions: which MAY be used to inform local-policy decisions:
o A list of the "d=" domains found in the validated (all) ARC-Seal o A list of the "d=" domains found in the validated (== all) ARC-
header fields; Seal header fields;
o The "d=" domain found in the most recent (highest instance number) o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily AMS header field (since that is the only one necessarily
validated) validated)
6.4.6. Reporting ARC Effects for DMARC Local Policy - Interim In the case of a failed chain, only the terminal ARC set is covered
by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC set.
9.5.2. Reporting ARC Effects for DMARC Local Policy - Interim
[[ Note: Discussion on the IETF DMARC-WG list has indicated some [[ Note: Discussion on the IETF DMARC-WG list has indicated some
interest in more substantial reporting for analytic purposes. To interest in more substantial reporting for analytic purposes. To
support that effort, the following guidance is provided only as an support that effort, the following guidance is provided only as an
interim, minimal data set. A more complete reporting construct will interim, minimal data set. A more complete reporting construct will
be specified in a related spec - TBD. (see also the note at be specified in a related spec - TBD. (see also the note at
Section 5.1.3) ]] Section 5.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions is augmented by adding a reporting of ARC-informed decisions is augmented by adding a
local_policy comment explanation as follows: local_policy comment explanation containing the list of data
discovered in the ARC evaluation (Section 9.5.1):
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail</spf> <spf>fail</spf>
<reason> <reason>
<type>local_policy</type> <type>local_policy</type>
<comment>arc=pass ams=d1.example d=d1.example,d2.example</comment> <comment>arc=pass ams=d2.example d=d2.example,d1.example</comment>
</reason> </reason>
</policy_evaluated> </policy_evaluated>
7. Privacy Considerations In the suggested sample, d2.example is the sealing domain for ARC[2]
and d1.example is the sealing domain for ARC[1].
The ARC-Seal chain provides a verifiable record of the handlers for a Mediators SHOULD generate DMARC reports on messages which transit
their system just like any other message which they receive. This
will result in multiple reports for each mediated message as they
transit the series of handlers. DMARC report consumers should be
aware of this behaviour and make the necessary accommodations.
10. Supporting Alternate Signing Algorithms
[[ Note: Some additional development of this section is needed. ]]
In the following branch diagrams, each algorithm is represented by an
'A' or 'B' at each hop to depict the ARC chain that develops over a
five hop scenario. 'x' represents a hop that does not support that
algorithm.
Note that during a transitional period where multiple algorithms are
allowed, all of the statements in this spec which refer to "exactly
one set of ARC headers per instance" need to be understood as "at
least one set per instance and no more than one instance-set per
algorithm".
10.1. Introductory Period
Intermediaries MUST be able to validate ARC chains build with either
algorithm but MAY create ARC sets with either (or both) algorithm.
The introductory period should be at least six (6) months.
10.2. Co-Existence Period
Intermediaries MUST be able to validate ARC chains build with either
algorithm and MUST create ARC sets with both algorithms. Chains
ending with either algorithm may be used for the result.
10.3. Deprecation Period
ARC sets built with algorithms that are being deprecated MAY be
considered valid within an ARC chain, however, intermediaries MUST
not create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years.
11. Privacy Considerations
The ARC chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this to match message. Anonymous remailers will probably not find this to match
their operating goals. their operating goals.
8. IANA Considerations 12. IANA Considerations
This specification adds three new header fields as defined below. This specification adds three new header fields as defined below.
8.1. Authentication-Results Method Registry Update 12.1. Authentication-Results Method Registry Update
This draft adds one item to the IANA "Email Authentication Methods" This draft adds one item to the IANA "Email Authentication Methods"
registry: registry:
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: chain evaluation result Property: chain evaluation result
Value: chain evaluation result status (see Section 5.1.1.1) Value: chain evaluation result status (see Section 5.3)
Status: active Status: active
Version: 1 Version: 1
8.2. Definitions of the ARC header fields 12.2. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
Author/Change controller: OAR-Dev Group Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC6376] Related information: [RFC6376]
o Header field name: ARC-Message-Signature o Header field name: ARC-Message-Signature
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
Author/Change controller: OAR-Dev Group Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC6376] Related information: [RFC6376]
o Header field name: ARC-Authentication-Results o Header field name: ARC-Authentication-Results
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC7601] Related information: [RFC7601]
9. Implementation Status 13. Implementation Status
[[ Note to the RFC Editor: Please remove this section before [[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC6982]. ]] publication along with the reference to [RFC6982]. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
skipping to change at page 19, line 15 skipping to change at page 16, line 17
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC6982], "this will allow reviewers and working groups This information is known to be correct as of the seventh
to assign due consideration to documents that have the benefit of interoperability test event which was held on 2017-07-15 & 16 at
running code, which may serve as evidence of valuable experimentation IETF99.
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
This information is known to be correct as of the third
interoperability test event which was held on 2016-06-17.
9.1. GMail test reflector and incoming validation 13.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT] Coverage: Full spec implemented as of [ARC-DRAFT-03]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality was demonstrated during the Implementation Notes: Full functionality was demonstrated during the
interop testing on 2016-06-17 interop testing on 2016-06-17
In place for reporting usage only as of 2016-11-21 on all GMail In place for reporting usage only as of 2016-11-21 on all GMail
flows. flows.
Rechecked general incoming validation as of 2017-02-24 interop event. Rechecked general incoming validation as of 2017-02-24 interop event.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [1]
9.2. AOL test reflector and internal tagging 13.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
Coverage: ARC chain validity status checking is not operational, but Coverage: ARC chain validity status checking is not operational, but
otherwise this system conforms to [ARC-DRAFT] otherwise this system conforms to [ARC-DRAFT-03]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality with the exception of chain Implementation Notes: Full functionality with the exception of chain
validity checking was demonstrated during the interop testing on validity checking was demonstrated during the interop testing on
2016-06-17 2016-06-17
Available for production mail via selected account whitelisting for Available for production mail via selected account whitelisting for
test validation only. test validation only.
Intermittent stability problems discovered at the interop event on Intermittent stability problems discovered at the interop event on
2017-02-24. Remediation underway as of the publication of this 2017-02-24. Remediation underway as of the publication of this
draft. draft.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [2]
9.3. dkimpy 13.3. dkimpy
Organization: dkimpy developers Organization: dkimpy developers
Description: Python DKIM package Description: Python DKIM package
Status of Operation: Production Status of Operation: Production
Coverage: The internal test suite is incomplete, but the command line Coverage: The internal test suite is incomplete, but the command line
developmental version of validator was demonstrated to interoperate developmental version of validator was demonstrated to interoperate
with the Google and AOL implementations during the interop on with the Google and AOL implementations during the interop on
2016-06-17 and the released version passes the tests in [ARC-TEST] 2016-06-17 and the released version passes the tests in [ARC-TEST]
https://github.com/ValiMail/arc_test_suite with both python and https://github.com/ValiMail/arc_test_suite with both python and
python3. python3.
Licensing: Open/Other (same as dkimpy package) Licensing: Open/Other (same as dkimpy package)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
9.4. OpenARC 13.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implemention of milter functionality related to the
OpenDKIM and OpenDMARC packages OpenDKIM and OpenDMARC packages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT] Coverage: Built to support [ARC-DRAFT-03]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: The build is FreeBSD oriented and takes some Implementation Notes: The build is FreeBSD oriented and takes some
tweaks to build on RedHat-based Linux platforms. tweaks to build on RedHat-based Linux platforms.
Initial testing during the Initial testing during the
interop event on 2016-06-17 showed that it can be operational, but the interop event on 2016-06-17 showed that it can be operational, but the
documentation regarding configuration settings is unclear and the documentation regarding configuration settings is unclear and the
generated signature values do not validate when compared to the Google, generated signature values do not validate when compared to the Google,
AOL or dkimpy implementations. AOL or dkimpy implementations.
Testing during the 2017-02-24 interop event showed that some of the Testing during the 2017-02-24 interop event showed that some of the
problems have been fixed, but there are still interoperability problems problems have been fixed, but there are still interoperability problems
when trying to use OpenARC in a "sandwich" configuration around a MLM. when trying to use OpenARC in a "sandwich" configuration around a MLM.
Contact Info: arc-discuss@dmarc.org [3] Contact Info: arc-discuss@dmarc.org [3]
9.5. Mailman addition 13.5. Mailman addition
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman package Description: Integrated ARC capabilities within the Mailman package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Unknown Coverage: Unknown
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Incomplete at this time Implementation Notes: Incomplete at this time
Contact Info: [https://www.gnu.org/software/mailman/contact.html] Contact Info: https://www.gnu.org/software/mailman/contact.html
9.6. Copernica/MailerQ web-based validation 13.6. Copernica/MailerQ web-based validation
Organization: Copernica Organization: Copernica
Description: Web-based validation of ARC-signed messages Description: Web-based validation of ARC-signed messages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT] Coverage: Built to support [ARC-DRAFT-03]
Licensing: On-line usage only Licensing: On-line usage only
Implementation Notes: Released 2016-10-24 Implementation Notes: Released 2016-10-24
Requires full message content to be pasted into a web form found at Requires full message content to be pasted into a web form found at
[http://arc.mailerq.com/] (warning - https is not supported). http://arc.mailerq.com/ (warning - https is not supported).
An additional instance of an ARC signature can be added if one is An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form. willing to paste a private key into an unsecured web form.
Initial testing shows that results match the other implementations Initial testing shows that results match the other implementations
listed in this section. listed in this section.
Contact Info: [https://www.copernica.com/] Contact Info: [https://www.copernica.com/]
9.7. Rspamd 13.7. Rspamd
Organization: Rspamd community Organization: Rspamd community
Description: ARC signing and verification module Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT] Coverage: Built to support [ARC-DRAFT-03]
Licensing: Open source Licensing: Open source
Implementation Notes: Released with version 1.6.0 on 2017-06-12 Implementation Notes: Released with version 1.6.0 on 2017-06-12
Contact Info: [https://rspamd.com/doc/modules/arc.html] and Contact Info: [https://rspamd.com/doc/modules/arc.html] and
[https://github.com/vstakhov/rspamd] [https://github.com/vstakhov/rspamd]
10. Security Considerations 13.8. PERL Mail::Milter::Authentication module
Organization: FastMail
Description: Email domain authentication milter, previously included
SPF / DKIM / DMARC, now has ARC added
Status of Operation: Intial validation completed during IETF99
hackathon with some follow-on work during the week
Coverage: Built to support [I-D.ARC]
Licensing: Open Source
Implementation Notes:
Contact Info: https://github.com/fastmail/authentication_milter
14. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly The Security Considerations of [RFC6376] and [RFC7601] apply directly
to this specification. to this specification.
Inclusion of ARC sets in the header of emails may cause problems for Inclusion of ARC sets in the header of emails may cause problems for
some older or more constrained MTAs if they are unable to accept the some older or more constrained MTAs if they are unable to accept the
greater size of the header. greater size of the header.
Operators who receive a message bearing N ARC sets has to complete Operators who receive a message bearing N ARC sets has to complete
N+1 DNS queries to evaluate the chain (barring DNS redirection N+1 DNS queries to evaluate the chain (barring DNS redirection
skipping to change at page 23, line 23 skipping to change at page 20, line 28
1. An attacker can send a message to an ARC partipant with a 1. An attacker can send a message to an ARC partipant with a
concocted sequence of ARC sets bearing the domains of intended concocted sequence of ARC sets bearing the domains of intended
victims, and all of them will be queried by the participant until victims, and all of them will be queried by the participant until
a failure is discovered. a failure is discovered.
2. DKIM only does one DNS check per signature, while this one can do 2. DKIM only does one DNS check per signature, while this one can do
many. Absent caching, slow DNS responses can cause SMTP many. Absent caching, slow DNS responses can cause SMTP
timeouts; this could be exploited as a DoS attack. timeouts; this could be exploited as a DoS attack.
10.1. Message Content Suspicion 14.1. Message Content Suspicion
Recipients are cautioned to treat messages bearing ARC sets with the Recipients are cautioned to treat messages bearing ARC sets with the
same suspicion that they apply to all other email messages. This same suspicion that they apply to all other email messages. This
includes appropriate content scanning and other checks for includes appropriate content scanning and other checks for
potentially malicious content. The handlers which are identified potentially malicious content. The handlers which are identified
within the ARC-Seal chain may be used to provide input to local within the ARC-Seal chain may be used to provide input to local
policy engines in cases where the sending system's DKIM-Signature policy engines in cases where the sending system's DKIM-Signature
does not validate. does not validate.
11. References 15. References
11.1. Normative References 15.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, DOI 10.17487/RFC1345, June 1992, RFC 1345, DOI 10.17487/RFC1345, June 1992,
<http://www.rfc-editor.org/info/rfc1345>. <http://www.rfc-editor.org/info/rfc1345>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 25, line 24 skipping to change at page 22, line 29
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>. <http://www.rfc-editor.org/info/rfc7208>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
11.2. Informative References 15.2. Informative References
[ARC-DRAFT] [ARC-DRAFT-03]
Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S.
Jones, "Authenticated Received Chain (ARC) Protocol Jones, "Authenticated Received Chain (ARC) Protocol
(I-D-03)", April 2017, <https://tools.ietf.org/html/draft- (I-D-03)", April 2017, <https://tools.ietf.org/html/draft-
ietf-dmarc-arc-protocol-03>. ietf-dmarc-arc-protocol-03>.
[ARC-TEST] [ARC-TEST]
Blank, S., "ARC Test Suite", January 2017, Blank, S., "ARC Test Suite", January 2017,
<https://github.com/ValiMail/arc_test_suite>. <https://github.com/ValiMail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
skipping to change at page 26, line 17 skipping to change at page 23, line 22
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<http://www.rfc-editor.org/info/rfc7960>. <http://www.rfc-editor.org/info/rfc7960>.
11.3. URIs 15.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org [2] mailto:arc-discuss@dmarc.org
[3] mailto:arc-discuss@dmarc.org [3] mailto:arc-discuss@dmarc.org
[4] mailto:dmarc@ietf.org [4] mailto:dmarc@ietf.org
[5] mailto:arc-discuss@dmarc.org [5] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Example Usage (Obsolete but retained for Appendix A. Appendix A - Example Usage (Obsolete but retained for
illustrative purposes) illustrative purposes)
[[ Note: The following examples were mocked up early in the [[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current definition process for the spec. They no longer reflect the current
definition and need various updates. ]] definition and need various updates which will be included in draft
-08. ]]
A.1. Example 1: Simple mailing list A.1. Example 1: Simple mailing list
A.1.1. Here's the message as it exits the Origin: A.1.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0) (authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569; by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST) Thu, 14 Jan 2015 15:00:01 -0800 (PST)
skipping to change at page 46, line 16 skipping to change at page 43, line 16
Please address all comments, discussions, and questions to Please address all comments, discussions, and questions to
dmarc@ietf.org [4]. Earlier discussions can be found at arc- dmarc@ietf.org [4]. Earlier discussions can be found at arc-
discuss@dmarc.org [5]. discuss@dmarc.org [5].
Authors' Addresses Authors' Addresses
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
1000 West Maude Ave 1000 West Maude Ave
Sunnyvale, California 94043 Sunnyvale, California 94085
USA USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
Steven Jones (editor) Steven Jones (editor)
TDP TDP
Email: smj@crash.com Email: smj@crash.com
Murray Kucherawy (editor)
TDP
Email: superuser@gmail.com
 End of changes. 152 change blocks. 
583 lines changed or deleted 470 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/