Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8617

The Authenticated Received Chain (ARC) Protocol

Pages: 35
Experimental
Part 1 of 2 – Pages 1 to 19
None   None   Next

Top   ToC   RFC8617 - Page 1
Internet Engineering Task Force (IETF)                       K. Andersen
Request for Comments: 8617                                      LinkedIn
Category: Experimental                                      B. Long, Ed.
ISSN: 2070-1721                                                   Google
                                                           S. Blank, Ed.
                                                                Valimail
                                                       M. Kucherawy, Ed.
                                                                     TDP
                                                               July 2019


            The Authenticated Received Chain (ARC) Protocol

Abstract

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

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are candidates for any level of
   Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8617.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8617 - Page 3

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7 3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Header Fields to Include in ARC-Seal Signatures . . . 15 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15 5.1.3. Only One Authenticated Received Chain per Message . . 16 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16 5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18 5.2.2. Responding to ARC Validation Failures during the SMTP Transaction . . . . . . . . . . . . . . . . . . . . . 19 6. Communication of Validation Results . . . . . . . . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Communicate Authentication Assessment across Trust Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19 7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20 7.2. Inform Message Disposition Decisions . . . . . . . . . . 21 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
Top   ToC   RFC8617 - Page 4
       7.2.2.  DMARC Reporting . . . . . . . . . . . . . . . . . . .  22
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     9.1.  Increased Header Field Size . . . . . . . . . . . . . . .  23
     9.2.  DNS Operations  . . . . . . . . . . . . . . . . . . . . .  23
     9.3.  Message Content Suspicion . . . . . . . . . . . . . . . .  24
     9.4.  Message Sealer Suspicion  . . . . . . . . . . . . . . . .  24
     9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     10.1.  Update to Email Authentication Result Names Registry . .  25
     10.2.  Update to Email Authentication Methods Registry  . . . .  25
     10.3.  New Header Fields in Permanent Message Header Field
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  26
     10.4.  New Status Code in Enumerated Status Codes Registry  . .  26
   11. Experimental Considerations . . . . . . . . . . . . . . . . .  27
     11.1.  Success Consideration  . . . . . . . . . . . . . . . . .  27
     11.2.  Failure Considerations . . . . . . . . . . . . . . . . .  27
     11.3.  Open Questions . . . . . . . . . . . . . . . . . . . . .  27
       11.3.1.  Value of the ARC-Seal (AS) Header Field  . . . . . .  27
       11.3.2.  Usage and/or Signals from Multiple Selectors and/or
                Domains in ARC Sets  . . . . . . . . . . . . . . . .  28
       11.3.3.  DNS Overhead . . . . . . . . . . . . . . . . . . . .  28
       11.3.4.  What Trace Information Is Valuable?  . . . . . . . .  28
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     12.2.  Informative References . . . . . . . . . . . . . . . . .  30
   Appendix A.  Design Requirements  . . . . . . . . . . . . . . . .  32
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  32
     A.2.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .  32
   Appendix B.  Example Usage  . . . . . . . . . . . . . . . . . . .  32
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1. Introduction

The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail by intermediate handlers. This impact is thoroughly documented in the defining documents for SPF and DKIM and further discussed in [RFC6377] and [RFC7960]. Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] also relies upon SPF and DKIM authentication mechanisms. Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected.
Top   ToC   RFC8617 - Page 5
   Authenticated Received Chain (ARC) creates a mechanism for individual
   Internet Mail Handlers to add their authentication assessment to a
   message's ordered set of handling results.  ARC encapsulates the
   authentication assessment in a DKIM signature derivative to grant
   other handlers the ability to verify the authenticity of the
   individual assessment assertion as well as the aggregate set and
   sequence of results.

   Ordered sets of authentication assessments can be used by ARC-enabled
   Internet Mail Handlers to inform message-handling disposition,
   identify where alteration of message content might have occurred, and
   provide additional trace information for use in understanding
   message-handling paths.

2. General Concepts

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

2.1. Evidence

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

2.2. Custody

"Custody" refers to when an Internet Mail Handler processes a message. When a handler takes custody of a message, the handler becomes a custodian and attaches its own evidence (authentication assessment upon receipt) to the message if it is ARC enabled. Evidence is added in such a way that future handlers can verify the authenticity of both evidence and custody.
Top   ToC   RFC8617 - Page 6

2.3. Chain of Custody

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

2.4. Validation of Chain of Custody

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

3. Terminology and Definitions

This section defines terms used in the rest of the document. Readers should to be familiar with the contents, core concepts, and definitions found in [RFC5598]. The potential roles of transit services in the delivery of email are directly relevant. Language, syntax (including some ABNF constructs), and concepts are imported from DKIM [RFC6376]. Specific references to DKIM are made throughout this document. The following terms are imported from [RFC5598]: o Administrative Management Domain (ADMD), Section 2.3 o Message Transfer Agent (MTA), Section 4.3.2 o Message Submission Agent (MSA), Section 4.3.1 o Message Delivery Agent (MDA), Section 4.3.3 Syntax descriptions use ABNF [RFC5234] [RFC7405]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Top   ToC   RFC8617 - Page 7

3.1. ARC Set

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

3.2. Authenticated Received Chain (ARC)

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

3.3. Internet Mail Handlers / Intermediaries

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

3.4. Authentication Assessment

The authentication assessment that is affixed to a message as part of each ARC Set consists of the "authres-payload" [RFC8601]. For the integrity of an ARC Set, the authentication assessment only needs to be properly encapsulated within the ARC Set as defined in Section 4.1. The accuracy or syntax of the authres-payload field does not affect the validity of the ARC Chain itself.
Top   ToC   RFC8617 - Page 8

3.5. Signing vs. Sealing

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

3.6. Sealer

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

3.7. Validator

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

3.8. Imported ABNF Tokens

The following ABNF tokens are imported: o tag-list ([RFC6376], Section 3.2) o authres-payload ([RFC8601], Section 2.2) o CFWS ([RFC5322], Section 3.2.2)

3.9. Common ABNF Tokens

The following ABNF tokens are used elsewhere in this document: position = 1*2DIGIT ; 1 - 50 instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position chain-status = ("none" / "fail" / "pass") seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status
Top   ToC   RFC8617 - Page 9

4. Protocol Elements

4.1. ARC Header Fields

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

4.1.1. ARC-Authentication-Results (AAR)

The ARC-Authentication-Results (AAR) header field records the message authentication assessment as processed by an ARC-participating ADMD at message arrival time. In general concept terms, the AAR header field is where evidence is recorded by a custodian. The AAR header field is similar in syntax and semantics to an Authentication-Results field [RFC8601], with two (2) differences: o the name of the header field itself and o the presence of the instance tag. Additional information on the instance tag can be found in Section 4.2.1. The formal ABNF for the AAR header field is: arc-info = instance [CFWS] ";" authres-payload arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info Because there is only one AAR allowed per ARC Set, the AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD, regardless of how many Authentication-Results header fields are attached to the message.

4.1.2. ARC-Message-Signature (AMS)

The ARC-Message-Signature (AMS) header field allows an ARC- participating ADMD to convey some responsibility (custodianship) for a message and possible message modifications to future ARC- participating custodians. In general concept terms, the AMS header field identifies a custodian.
Top   ToC   RFC8617 - Page 10
   The AMS header field has the same syntax and semantics as the DKIM-
   Signature field [RFC6376], with three (3) differences:

   o  the name of the header field itself;

   o  no version tag ("v") is defined for the AMS header field.  As
      required for undefined tags (in [RFC6376]), if seen, a version tag
      MUST be ignored; and

   o  the "i" (Agent or User Identifier (AUID)) tag is not imported from
      DKIM; instead, this tag is replaced by the instance tag as defined
      in Section 4.2.1.

   ARC places no requirements on the selectors and/or domains used for
   the AMS header field signatures.

   The formal ABNF for the AMS header field is:

   arc-ams-info = instance [CFWS] ";" tag-list
   arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info

   To reduce the chances of accidental invalidation of AMS signatures:

   o  AMS header fields are added by ARC-participating ADMDs as messages
      exit the ADMD.  AMS header fields SHOULD be attached so that any
      modifications made by the ADMD are included in the signature of
      the AMS header field.

   o  Authentication-Results header fields MUST NOT be included in AMS
      signatures as they are likely to be deleted by downstream ADMDs
      (per [RFC8601], Section 5).

   o  ARC-related header fields (ARC-Authentication-Results, ARC-
      Message-Signature, and ARC-Seal) MUST NOT be included in the list
      of header fields covered by the signature of the AMS header field.

   To preserve the ability to verify the integrity of a message, the
   signature of the AMS header field SHOULD include any DKIM-Signature
   header fields already present in the message.
Top   ToC   RFC8617 - Page 11

4.1.3. ARC-Seal (AS)

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

4.1.4. Internationalized Email (EAI)

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

4.2. ARC Set

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

4.2.1. Instance Tags

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

   For handling multiple signing algorithms, see [ARC-MULTI].

4.3. Authenticated Received Chain

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

4.4. Chain Validation Status

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

5. Protocol Actions

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

5.1. Sealer Actions

To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC header fields AAR, AMS, and AS) to a message. All ARC header fields in an ARC Set share the same instance tag value. To perform sealing (aka to build and attach a new ARC Set), the following actions must be taken by an ARC Sealer when presented with a message: 1. All message modifications (including adding a DKIM-Signature header field(s)) MUST be performed before sealing. 2. If the message already contains an Authenticated Received Chain with the most recent AS reporting "cv=fail", there is no need to proceed and the algorithm stops here. 3. Calculate the instance value. If the message already contains an Authenticated Received Chain, the instance value is 1 more than the highest instance number found in the Authenticated Received Chain. If no Authenticated Received Chain exists, the instance value is 1.
Top   ToC   RFC8617 - Page 15
   4.  Using the calculated instance value, generate and attach a
       complete ARC Set to the message as follows:

       A.  Generate and attach an ARC-Authentication-Results header
           field as defined in Section 4.1.1.

       B.  Generate and attach an ARC-Message-Signature header field as
           defined in Section 4.1.2.

       C.  Generate and attach an ARC-Seal header field using the AS
           definition found in Section 4.1.3, the prescribed headers
           defined in Section 5.1.1, and the Chain Validation Status as
           determined during ARC validation.

5.1.1. Header Fields to Include in ARC-Seal Signatures

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

5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains

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

5.1.3. Only One Authenticated Received Chain per Message

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

5.1.4. Broad Ability to Seal

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

5.1.5. Sealing Is Always Safe

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

5.2. Validator Actions

A Validator performs the following steps, in sequence, to process an Authenticated Received Chain. Canonicalization, hash functions, and signature validation methods are imported from [RFC6376], Section 5. 1. Collect all ARC Sets currently attached to the message. * If there are none, the Chain Validation Status is "none", and the algorithm stops here. * The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist, the Chain Validation Status is "fail", and the algorithm stops here. * In the following algorithm, the maximum discovered ARC instance value is referred to as "N". 2. If the Chain Validation Status of the highest instance value ARC Set is "fail", then the Chain Validation Status is "fail", and the algorithm stops here. 3. Validate the structure of the Authenticated Received Chain. A valid ARC has the following conditions: A. Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS). B. The instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition. C. The "cv" value for all ARC-Seal header fields MUST NOT be "fail". For ARC Sets with instance values > 1, the values MUST be "pass". For the ARC Set with instance value = 1, the value MUST be "none". * If any of these conditions are not met, the Chain Validation Status is "fail", and the algorithm stops here. 4. Validate the AMS with the greatest instance value (most recent). If validation fails, then the Chain Validation Status is "fail", and the algorithm stops here.
Top   ToC   RFC8617 - Page 18
   5.  _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by
       validating each prior AMS beginning with N-1 and proceeding in
       decreasing order to the AMS with the instance value of 1:

       A.  If an AMS fails to validate (for instance value "M"), then
           set the oldest-pass value to the lowest AMS instance value
           that passed (M+1), and go to the next step (there is no need
           to check any other (older) AMS header fields).  This does not
           affect the validity of the Authenticated Received Chain.

       B.  If all AMS header fields verify, set the oldest-pass value to
           zero (0).

   6.  Validate each AS beginning with the greatest instance value and
       proceeding in decreasing order to the AS with the instance value
       of 1.  If any AS fails to validate, the Chain Validation Status
       is "fail", and the algorithm stops here.

   7.  If the algorithm reaches this step, then the Chain Validation
       Status is "pass", and the algorithm is complete.

   The end result of this validation algorithm SHOULD be included within
   the Authentication-Results header field for the ADMD.

   As with a DKIM signature ([RFC6376], Section 6.3) that fails
   verification, a message with an Authenticated Received Chain with a
   Chain Validation Status of "fail" MUST be treated the same as a
   message with no Authenticated Received Chain.

   _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
   Received Chain can use that information as part of a wider handling
   context.  ARC adoption cannot be assumed by intermediaries; many
   intermediaries will continue to modify messages without adding ARC
   seals.

5.2.1. All Failures Are Permanent

Authenticated Received Chains represent the traversal of messages through one or more intermediaries. All errors, including DNS failures, become unrecoverable and are considered permanent. Any error validating an Authenticated Received Chain results in a Chain Validation Status of "fail". For further discussion of this topic and the design restriction that prevents chain continuation or re-establishment, see [ARC-USAGE].
Top   ToC   RFC8617 - Page 19

5.2.2. Responding to ARC Validation Failures during the SMTP Transaction

If an ARC Validator determines that the incoming message fails ARC validation, the Validator MAY signal the breakage through the extended SMTP response code 5.7.29 ("ARC validation failure") and the corresponding SMTP basic response code. Because ARC failures are likely only to be detected in the context of other underlying authentication mechanism failures, Validators MAY use the more general 5.7.26 ("Multiple authentication checks failed") instead of the ARC-specific code.

6. Communication of Validation Results

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


(page 19 continued on part 2)

Next Section