Independent Stream                                             W. Chuang
Internet-Draft                                              Google, Inc.
Intended status: Experimental                                B. Gondwana
Expires: 10 November 2023                               Fastmail Pty Ltd
                                                              9 May 2023


             Replay Resistant Authenticated Receiver Chain
                  draft-chuang-replay-resistant-arc-06

Abstract

   DKIM (RFC6376) is an IETF standard for the cryptographic protocol to
   authenticate email at the domain level and protect the integrity of
   messages during transit.  Section 8.6 defines a vulnerability called
   DKIM Replay as a spam message sent through a SMTP MTA DKIM signer,
   that then is sent to many more recipients, leveraging the reputation
   of the signer.  We propose two Replay Resistant cryptographic domain
   based protocols that leverage ARC (RFC8617).  The first technique
   discloses all SMTP recipients as signed RFC822 headers by the sender
   which allows a receiver to verify this.  The second technique defines
   a SMTP extension that allows both the sender and receiver to
   participate in signing the message signature.  It includes a path
   building technique that accurately defines the SMTP forwarding path
   of the message.  Both techniques permit a receiver to detect DKIM and
   ARC replay attacks and other attacks.  This specification also
   defines a relay flow identifier to prevent spammers from using relay
   forwarding.  We do this by having relays categorize their
   authenticated traffic flows and publish to receivers identifiers
   associated with those flows.  Receivers can use this identifier to
   help categorize traffic through the relay and use that identifier to
   apply fine-grain anti-abuse policies instead of on the entire traffic
   through the relay.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Chuang & Gondwana       Expires 10 November 2023                [Page 1]

Internet-Draft            Replay Resistant ARC                  May 2023


   This Internet-Draft will expire on 10 November 2023.

Copyright Notice

   Copyright (c) 2023 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology and Definitions . . . . . . . . . . . . . . .   4
       1.1.1.  Definitions . . . . . . . . . . . . . . . . . . . . .   4
       1.1.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Defining and Propagating Sender Identity in Mail Flow . . . .   6
   3.  Declare All Recipients and Affirm (DARA)  . . . . . . . . . .   7
     3.1.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Declaring All Recipients  . . . . . . . . . . . . . .   7
       3.1.2.  Protocol Awareness  . . . . . . . . . . . . . . . . .   8
       3.1.3.  Receiver Verification . . . . . . . . . . . . . . . .   9
       3.1.4.  3rd Party Verification  . . . . . . . . . . . . . . .  10
     3.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .  11
     3.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.3.1.  Originator ==> Mailing-List ==> Receiver  . . . . . .  11
       3.3.2.  Originator ==> First Receiver; Replay ==> Victim
               Receiver  . . . . . . . . . . . . . . . . . . . . . .  12
       3.3.3.  Originator ==> Naive-Forwarder ==> Receiver . . . . .  13
   4.  Sender Receiver Co-Signing (SeRCi)  . . . . . . . . . . . . .  13
     4.1.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .  14
       4.1.1.  SMTP Extension  . . . . . . . . . . . . . . . . . . .  15
       4.1.2.  Protocol Awareness  . . . . . . . . . . . . . . . . .  16
       4.1.3.  Receiver Verification . . . . . . . . . . . . . . . .  17
       4.1.4.  Definitions . . . . . . . . . . . . . . . . . . . . .  17
     4.2.  Header Example  . . . . . . . . . . . . . . . . . . . . .  18
   5.  Relay Flow Identifier . . . . . . . . . . . . . . . . . . . .  18
     5.1.  Flow Identification Token . . . . . . . . . . . . . . . .  19
     5.2.  ARC Authentication-Result Method  . . . . . . . . . . . .  19
   6.  Chain of Custody  . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Chain Building Algorithm  . . . . . . . . . . . . . . . .  20
     6.2.  Modified Body Algorithm . . . . . . . . . . . . . . . . .  23



Chuang & Gondwana       Expires 10 November 2023                [Page 2]

Internet-Draft            Replay Resistant ARC                  May 2023


     6.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .  23
   7.  Chaining Header Examples  . . . . . . . . . . . . . . . . . .  24
     7.1.  Originator ==> Mailing-List ==> Receiver  . . . . . . . .  24
     7.2.  Originator ==> Naive-Forwarder ==>Aware-Forwarder
           ==>Aware-Receiver . . . . . . . . . . . . . . . . . . . .  25
     7.3.  Originator ==> Receiver ; Spammer ==> Victim Receiver . .  25
     7.4.  Spammer ==> Gullible Forwarder ==> Receiver . . . . . . .  26
     7.5.  Originator ==> Modifying Forwarder ==> Receiver . . . . .  27
     7.6.  Spammer ==> Relay ==> Receiver  . . . . . . . . . . . . .  27
   8.  DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . .  28
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  28
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  28
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   12. Informative References  . . . . . . . . . . . . . . . . . . .  28
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   This protocol provides two different techniques to authenticate email
   by domain that is replay resistant.  These two techniques are
   independent of each other with different methods, benefits and
   limitations in tackling replay.  Both are presented in case the
   limitations of one precludes using it.  It leverages the features of
   ARC to name ADMD in the email forwarding path and the intermediate
   results.  The first technique discloses all SMTP recipients as signed
   RFC822 headers by the sender which allows a receiver to verify this.
   This is further divided into a base form and more comprehensive
   version.  The second technique defines a SMTP extension that allows
   both the sender and receiver to participate in signing the message
   signature, and can be built into a path of signing ADMDs called
   chaining.  The results of the two techniques MAY be used by spam
   filtering to apply some local policy, and/or applied to DMARC policy
   evaluation as one of its input email authenticators.  These
   techniques depend on DKIM and ARC to indicate use of the protocol,
   and depend upon ARC to publish the results.

   Existing email authentication techniques have known limitations.
   DKIM suffers from being vulnerable to replay attacks as described in
   draft-chuang-dkim-replay-problem (https://datatracker.ietf.org/doc/
   draft-chuang-dkim-replay-problem/).  Spammers utilize an account on a
   sender that supports signing with DKIM to capture a spammy message
   with a valid DKIM signature.  The spam is then broadcast to many
   victim recipients.  Because ARC is based on DKIM signing, ARC is
   similarly vulnerable to replay.  Spammers utilize relays to obfuscate
   their identities and often to spoof some other identity with email
   receivers.  For example a spammer may exploit the shared tenancy
   vulnerability of SPF to spoof some identity as follows.  The find a



Chuang & Gondwana       Expires 10 November 2023                [Page 3]

Internet-Draft            Replay Resistant ARC                  May 2023


   relay that hosts many different enterprise customers who include the
   relay's IPs in their SPF policies.  The spammer then sends traffic
   through the relay assuming the identity of one of those customers
   i.e. it spoofs the MAIL FROM identity of the victim domain.  While
   the SPF validation (if done) of the initial send by the spammer to
   the relay fails, a subsequent SPF validation when forwarded to some
   other victim receiver from the relay will pass SPF because the IPs
   are contained in the victim's SPF policy.  At some point, the
   receiver notices the spam via the relay and wants to apply anti-abuse
   counter measures.  With existing authentication methods, this policy
   would impact all mail flows through that relay, both innocent and
   malicious.  A better approach would be to selectively apply anti-
   abuse counter measures to the spammer's flow which is what this
   proposal enables.

   The broader goals of these proposals are outlined here:

   *  Any party can independently verify that a message traveled along a
      path as intended by the originator (original sender) to the
      receiver (last receiver).  This prevents DKIM and ARC replay
      attacks, and SPF shared tenancy attacks.

   *  Receivers can determine if the message was modified along the path
      and by whom.

   *  Be able to tolerate parties not participating in the new protocol.
      Make sure to have reasonable partial failure modes for non-
      participating parties including incentives to encourage future
      participation.

1.1.  Terminology and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1.1.  Definitions

   SMTP transport and particular email senders and receivers are defined
   in [RFC5321].  Email payload and headers are defined in [RFC5322].
   This document uses [RFC5598] email flow definitions, which describes
   the interactions between the parties in sending email.  In particular
   these parties assist the email senders and receivers in email
   transport.  draft-chuang-dkim-replay-problem
   (https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/)
   adds context to those mailflows for the DKIM replay problem.





Chuang & Gondwana       Expires 10 November 2023                [Page 4]

Internet-Draft            Replay Resistant ARC                  May 2023


1.1.2.  Acronyms

   ADMD:  ADministrative Management Domain is defined as [RFC5598] and
      represents the independent operational scope authorship, handling,
      and receiving.

   ARC:  Authenticated Received Chain [RFC8617] - is a protocol that is
      meant to resolve some of the issues for DMARC [RFC7489] to fix the
      problems that DMARC policy rejects caused by mail forwarding.  ARC
      uses a digital signing mechanism derived from DKIM to protect the
      integrity of the Authentication-Results of a forwarder and a
      versioning mechanism to describe the forwarders.  ARC suffers from
      similar replay issues as DKIM.

   Authentication-Results:  A header containing a list of email
      authentication validation methods, results and comments as
      specified in [RFC8601].

   DKIM:  DomainKeys Identified Mail [RFC6376] standard for the
      cryptographic protocol to authenticate email at the domain level
      and protect the integrity of messages during transit.

   DKIM replay  As defined in [RFC6376] section 8.6- a vulnerability
      called DKIM Replay as a spam message sent through a SMTP MTA DKIM
      signer, that then is sent to many more recipients, leveraging the
      reputation of the signer.

   DMARC:  Domain-based Message Authentication, Reporting, and
      Conformance [RFC7489]- defines a sender defined message handling
      policy for spoofed messages to be applied when a message is
      delivered at some receiving SMTP server.

   MDA  Message Delivery Agent defined in [RFC5598].

   MSA  Message Submission Agent defined in [RFC5598].

   MTA  Message Transfer Agent defined in [RFC5598].

   SPF:  Sender Policy Framework [RFC7208] standard for authenticating
      sending servers typically based on IP address.











Chuang & Gondwana       Expires 10 November 2023                [Page 5]

Internet-Draft            Replay Resistant ARC                  May 2023


2.  Defining and Propagating Sender Identity in Mail Flow

   This section outlines how ARC and DKIM are used by the email
   authentication methods defined in this document, though several
   details are left for later.  This specification mandates that the
   ADMDs participating in either of these two protocols explicitly
   identify themselves with a DKIM signature or as an ARC set including
   and ARC seal.  Participants should use ARC set if they expect the
   message to be modified in the mail-flow otherwise a DKIM signature
   suffices.  Participants will then formulate an identified path of
   ADMD nodes from the originator ADMD to the receiving ADMD.  If the
   message exits the identified path into some naive, unaware ADMD the
   aware ADMD denotes this allowing for mitigations for this scenario.
   The MSA ADMD i.e. the responsible originating sender may sign the
   message with DKIM or with ARC.  This protocol requires that the
   _From_ header domain alignment with the email authentication method
   i.e.  MUST be the same as the DKIM "d=" domain or ARC-Seal "d=
   domain.  This ties the sender's identity to the cryptographic signer
   that claims that.  If the originator performs ARC signing, the ARC
   the ARC-Authentication-Results MUST be empty.  When the message is
   delivered to the inbox by the MDA ADMD at ARC set "i=N", it MAY strip
   the ARC-Seal and ARC-Message-Signature but leave behind the ARC-
   Authentication-Result.  Partially stripping the ARC set makes
   termination identifiable and more difficult to replay as signatures
   are missing.  A message lacking ARC-Seal and ARC-Message-Signatures
   has been delivered to the inbox.

   This protocol leverages DKIM and ARC for declaring protocol settings
   and protecting the integrity of the headers and message body, and ARC
   for propagating authentication results.  At the message originator,
   this uses DKIM DKIM tag/values for declaring settings and optionally
   ARC-Seal tag/values instead.  For message forwarding, this uses ARC-
   Seal tag/values for declaring settings.  After the email receiver
   evaluates the email authentication results, these results are
   published and propagated to the subsequent receivers via ARC-
   Authentication-Results.  The two protocols in this document updates
   ARC-Authentication-Results method status, properties and comments.
   The specific tag/values and ARC-Authentication-Result methods will be
   defined in the specific protocol section.

   To prevent reuse of ARC headers from one message in another, this
   protocol mandates generating the ARC-Message-Signature signature upon
   any outbound traversal from one ADMD to a different ADMD.  In
   addition there MAY be ARC signing internal to the ADMD.  Having this
   outbound message body signing invariant permits the receiver to
   verify the integrity of the message as sent by the prior ADMD.  To
   verify the integrity of the ARC sets then, a receiver MUST verify the
   previous ARC set's ARC-Message-Signature and verify each ARC set's



Chuang & Gondwana       Expires 10 November 2023                [Page 6]

Internet-Draft            Replay Resistant ARC                  May 2023


   ARC-Seal signature from "i=N" (sender's ARC set number) to "i=1" as
   well as the presence of all headers in the ARC set.  Failure of the
   ARC-Message-Signature verification from the immediate sender at "i=N"
   is treated differently than failures from prior senders at "i=N-1" or
   earlier with the intention that verifiers MAY potentially use the
   subsequent ARC set verification results hence differentiated.  If the
   receiver sees a verification failure from the immediate sender's ARC-
   Message-Signature as "hard" _fail_.  ARC-Seal verification failures
   from "i=N-1" to "i=1" are tolerated, meaning their failure does not
   indicate a failing ARC result.  ARC-Seal verification failures from
   "i=N" to "i=1" are treated also as "hard" _fail_.  The result of the
   verification is published in the Authentication-Result and the ARC-
   Authentication-Result with a tag "arc=".  Even if ARC verification
   fails, this specification asks the receiver to continue ARC
   generation and verification to provide forensics evidence for
   subsequent receivers via the authentication results.  For example the
   SPF authentication results of the potentially malicious sender MAY
   help identify that sender to some subsequent receiver.  The
   propagated ARC verification failure will help prevent inadvertent use
   of the authentication results by subsequent receivers.

3.  Declare All Recipients and Affirm (DARA)

3.1.  Concepts

   This first email authentication protocol uses validating signed
   headers against the envelope headers.  It features a look up
   mechanism to support forwarders that are unaware of the protocol.
   Also it publishes enough information for a third party to
   independently validate the results given by SMTP sender and receiver.

3.1.1.  Declaring All Recipients

   We create an email authentication protocol resistant against replay
   attacks by explicitly identifying all recipients in the headers,
   including when the recipient is "hidden" such as _Bcc:_ or Mailing-
   lists.  That way when a signed message arrives, the receiver can
   check if the RCPT TO recipient correctly is a subset of the recipient
   in the signed message header.  If not, then the message MAY be part
   of a replay attack.  To: and Cc: recipients are appropriately
   declared.  Those headers MUST be signed by DKIM or ARC-Message-
   Signature.  For blind carbon copy, while a Bcc: header MAY be added,
   it can be stripped by subsequent forwarders.  Instead we create a new
   _Forwarded-to: _ header that includes an ARC set versioning number to
   indicate which ADMD sent the message to a new recipient.  At the
   origination, if no ARC headers are provided, the ARC set number is
   set to 0.




Chuang & Gondwana       Expires 10 November 2023                [Page 7]

Internet-Draft            Replay Resistant ARC                  May 2023


   Forwarded-to: i=1; user@example.com

   As part of the DARA protocol, recipients not declared by To: or Cc:
   MUST be declared with the _Forwarded-to:_ header.  This supports the
   email forwarder and mailing list scenario where we also use the
   _Forwarded-to_ header to indicate that a message is sent to a new
   recipient.  _Forwarded-to: _MUST be propagated by forwarders
   unmodified.  For the privacy of "hidden" recipients and to prevent
   their identity from being visible to other recipients via the
   _Forwarded-to: header_, the message MUST be split and signed
   exclusively for each _Forwarded-to:_ recipient.  This means the
   header is visible only to that recipient.  Messages sent to a new
   ADMD but with the same recipient identity disclosed by _Forwarded-to_
   MAY reuse the prior header.

   To protect the integrity of the _Forwarded-to:_ header, they MUST be
   hashed and signed by ARC-Seal as follows: Collect all _Forwarded-to:_
   headers and hash them following the header processing algorithm in
   RFC6376 (https://www.rfc-editor.org/rfc/rfc6376#section-5.4) section
   5.4.  This hash is published in the ARC-Seal header as "fh=" tag and
   base64 hash value.  DARA aware verifiers can recompute the hash and
   check it against the hash contained in the "fh=" tag to verify the
   integrity of the _Forwarded-to:_ headers.  For example:

3.1.2.  Protocol Awareness

   Senders and receivers MAY variously support the DARA protocol or not,
   so the protocol needs to be tolerant of ADMDs that don't support the
   protocol.  For example a naive mailing list sender sending to a
   protocol aware receiver SHOULD NOT have traffic rejected simply
   because it didn't follow the protocol.  Yet simultaneously, the DARA
   protocol needs to discourage abuse by spammers seeking to use the
   naive ADMD path for DKIM replay.  The protocol calls for the DARA
   aware senders to lookup the capability of the receiver in supporting
   DARA and disclose that capability in the message.  The following
   describes procedure for the look up, and the following paragraph
   describes the disclosure statement.  All ADMD supporting the DARA
   protocol MUST publish a DNS txt policy record.  The DARA aware sender
   MUST look up the receiver's policy record as described next or use
   other mechanisms to determine whether the receiver supports DARA.  A
   sender may also keep a list of receivers that support DARA.

   The sender discovers the receiver's support for this protocol by a
   DNS TXT policy lookup upon the recipient email address domain.  The
   format of the policy record are tag/values in form of the textual
   representation in RFC6376 (https://www.rfc-editor.org/rfc/
   rfc6376#section-3.2) section 3.2.  The policy must start with DARA
   version t this policy record MAY be a tag value indicating which



Chuang & Gondwana       Expires 10 November 2023                [Page 8]

Internet-Draft            Replay Resistant ARC                  May 2023


   SeRCi version number "v=" which MUST be set to "DARA_1.0" when that
   ADMD indicates it supports DARA.  The lookup also discovers the
   normalized destination domain name, and that destination domain MUST
   match the ADMD ARC-Seal "d=" domain [RFC8617] which enables tracing
   this domain _From_ sender to receiver as described later.  The domain
   name is specified "dara=<domain>" in the DNS policy record.  Once
   discovered this domain is put in the sender's DKIM-Signature or ARC-
   Seal as"dara=<domain>", which indicates support by the receiver for
   the SeRCi as well as identify the intended receiver domain.  The
   following is an example of a DARA aware DNS policy record for
   example.org:

   v=DARA_1.0; serci=example.com

   If no such DNS txt policy record is found, then the receiver does not
   support the SeRCi protocol.  This is indicated in the ARC-Seal by a
   SeRCi naive receiver tag/value of "darn=" and _From_ header domain
   for path building described later.  Further the "darn=" tag indicates
   to subsequent DARA aware receivers that there was an intermediate
   naive forwarder.  Also, when there is spam, instead of penalizing the
   sender that is DARA aware, the receiver MAY elect to apply the
   reputation penalty to the receiving domain that is naive to DARA.

   A DARA aware receiver MAY elect to check the sender's policy if it
   suspects that a MiTM has stripped off the sender's DARA policy.  If
   it detects a DARA declaration in the DNS policy, but not in the
   message, the receiver MAY elect to treat the message as spam.

3.1.3.  Receiver Verification

   A DARA aware receiver looks in the message to determine how to do
   DARA validation.  First it looks for the most recent ARC-Seal if any
   using the ARC set number to determine recency.  If not found then it
   looks for a DKIM-Signature.  When found, a DARA aware receiver
   verifies the integrity of header, then looks for a DARA tag/values
   and these are interpreted as follows.  If the tag is "dara=", then
   the receiver MUST validate the recipients, and if it fails
   verification, treat the message as DARA unauthenticated with the
   implication that the message is being replayed.  As with other email
   authentication methods, the verifier is free to apply a locally
   defined policy against unauthenticated email.  After applying any
   local policy, it SHOULD treat validation success as _pass_, and
   validation failure as _fail_.  If the tag is "darn=" the receiver MAY
   choose to validate the recipients or not.  If a receiver validates
   the recipients, it SHOULD treat recipient verification failure as
   _neutral_ and SHOULD treat success as _pass_.  This discretionary
   validation mode is to support the scenario of DARA unware ADMDs that
   may cause innocent validation failures.  The domain value associated



Chuang & Gondwana       Expires 10 November 2023                [Page 9]

Internet-Draft            Replay Resistant ARC                  May 2023


   with "darn=" tag provided may help identify that intermediary ADMD
   when there are multiple recipients.  That domain may provide clues
   for email authentication.

   The receiver's verification process is to collect all the recipients
   in the _To_, _Cc_ and _Forwarded-to_ headers.  It verifies that they
   are signed appropriately in the sender's DKIM-Signature or ARC-
   Message-Signature, and if not fails the verification.  If so, the
   receiver then collects all the RCPT TO recipients as the envelope
   recipients.  The receiver then verifies that the envelope recipients
   are a subset of the signed headers.  It applies the "dara=" or
   "darn=" policy as described above.  The result of this verification
   MUST be published in the ARC-Authentication-Results as "dara"
   [RFC8601] method with a result of _pass_ or _fail_ or _neutral_.
   Receivers MUST declare the RCPT TO identity of that the message was
   received as a property header.i=<recipient email address>.  This is
   to enable 3rd party mail flow validation as will be described
   shortly.  For example the ARC-Authentication-Result could look like:

   ARC-Authentication-Result: i=2; dara=pass header.i=user@example.com

3.1.4.  3rd Party Verification

   A third party verifier MUST be able to verify that DARA transaction
   between the sender and receiver occurred successfully or not using
   the message headers.  This procedure can later be used by the Chain
   verification algorithm.  First the verifier identifies the sender and
   receiver.  The sender may be identified by the policy declaration in
   the DKIM-Signature or ARC-Seal with a ARC set number preceding the
   receiver.  The receiver may be identified by the results found in the
   ARC-Authentication-Results with an ARC set number i=1 if the sender
   is a DKIM-Signature or incremented by one from the receiver's.  In
   both cases the integrity of the headers are checked.  If using a
   DKIM-Signature, validating the signature and "fh=" hash.  If an ARC
   set, then checking the ARC-Seal and then the "fh=" hash.  If it
   passes, then verifier determines the sender's declaration of the
   receiver's DARA support, by looking for "dara=" tag in the DKIM-
   Signature or ARC-Seal.  The value of the "dara=" domain MUST match
   the receiver's ARC-Seal's "d=" domain, and the receiver's ARC seal
   MUST verify.  The 3rd party verifier SHOULD also check to see if the
   ARC-Authentication-Result "header.i=" is a subset of the declared and
   signed header so far.  If these step pass, the 3rd party verification
   _passes_.  If verification at any individual fails, the 3rd party
   verification _fails_.







Chuang & Gondwana       Expires 10 November 2023               [Page 10]

Internet-Draft            Replay Resistant ARC                  May 2023


3.2.  Definitions

   DNS TXT Policy tag/values

   *  "v=": Value of "DARA_1.0" if the ADMD supports the DARA
      verification protocol.

   *  "dara=": Value of the receiver's ARC-Seal "d=" domain

   DKIM-Signature or ARC-Seal tags/values

   *  "dara=": Value of the receiver's ARC-Seal "d=" domain when the
      receiver is DARA capable found from the DARA DNS policy record.

   *  "darn=": Value of RFC822 recipient's domain name when the receiver
      is naive of DARA.

   ARC-Authentication-Results method

   *  "dara=": Value of _pass_ if recipient validation passes, otherwise
      _fail_.  In some circumstances this tag/value may be unset or be
      treated as _neutral_.

3.3.  Examples

3.3.1.  Originator ==> Mailing-List ==> Receiver

   Originator outbound

  DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
  To: list@mailinglist.example.com

   Mailing-List inbound (after ARC seal)

  ARC-Seal: i=1; d=mailinglist.example.com;
  ARC-Authentication-Results: i=1; dara=pass
       header.i=list@mailinglist.example.com (rcpt.to
       list@mailinglist.example.com matches signed header)
  DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
  To: list@mailinglist.example.com

   Mailing-List outbound (after ARC reseal)









Chuang & Gondwana       Expires 10 November 2023               [Page 11]

Internet-Draft            Replay Resistant ARC                  May 2023


  Forwarded-to: i=1; user@receiver.example.org
  ARC-Seal: i=1; d=mailinglist.example.com; fh=...
  ARC-Authentication-Results: i=1; dara=pass
       header.i=list@mailinglist.example.com (rcpt.to
       list@mailinglist.example.com matches signed header)
  DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
  To: list@mailinglist.example.com

   Receiver inbound (after ARC seal)

  ARC-Seal: i=2; d=receiver.example.org; fh=...
  ARC-Authentication-Results: i=2; dara=pass
          header.i=user@receiver.example.org (rcpt.to
          user@receiver.example.org matches signed header)
  Forwarded-to: i=1; user@receiver.example.org
  ARC-Seal: i=1; d=mailinglist.example.com; fh=...
  ARC-Authentication-Results: i=1; dara=pass
       header.i=list@mailinglist.example.com (rcpt.to
       list@mailinglist.example.com matches signed header)
  DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
  To: list@mailinglist.example.com

3.3.2.  Originator ==> First Receiver; Replay ==> Victim Receiver

   Originator outbound (after ARC seal)

   DKIM-Signature: d=originator.example.com; dara=receiver.example.com
   To: user@receiver.example.com

   First receiver inbound (after ARC seal)

   ARC-Seal: i=1; d=receiver.example.com
   ARC-Authentication-Results: i=1; dara=pass
        header.i=user@receiver.example.com (rcpt.to
        user@receiver.example.com matches signed header)
   DKIM-Signature: d=originator.example.com; dara=receiver.example.com
   To: user@receiver.example.com

   Above message captured by spammer, modified (add additional headers)
   and then resent.  A spammer might send the message to
   john.doe@victim.example.net which would be unspecified in the
   headers.

   Victim (last) receiver inbound (after ARC seal)







Chuang & Gondwana       Expires 10 November 2023               [Page 12]

Internet-Draft            Replay Resistant ARC                  May 2023


   ARC-Seal: i=2; d=victim.example.net
   ARC-Authentication-Results: i=2; dara=fail
        header.i=john.doe@victim.example.net (rcpt.to
        john.doe@victim.example.net mismatches signed header);
   ARC-Seal: i=1; d=receiver.example.com
   ARC-Authentication-Results: i=1; dara=pass
        header.i=user@receiver.example.com (rcpt.to
        user@receiver.example.com matches signed header)
   DKIM-Signature: d=originator.example.com; dara=receiver.example.com
   To: user@receiver.example.com

3.3.3.  Originator ==> Naive-Forwarder ==> Receiver

   This describes a message sent throug Bcc to a forwarder that does not
   support DARA.

   First outbound (after ARC seal)

   Forwarded-to: i=0; user@naive.example.com
   DKIM-Signature: darn=naive.example.com; fh=...

   The naive forwarder changes the recipient address from
   user@naive.example.com to user@aware.example.com, and the envelope
   recipient will change accordingly.  aware.xample.com supports DARA.

   Final inbound (after ARC seal).

   ARC-Seal: i=1; d=aware.example.com
   ARC-Authentication-Results: i=1; dara=fail
        header.i=user@aware.example.com (rcpt.to
        user@aware.example.com mismatches signed header);
   Forwarded-to: i=0; user@naive.example.com
   DKIM-Signature: darn=naive.example.com; fh=...

   At receiver, the declared and signed recipient user@naive.example.com
   will mismatch the envelope recipient user@aware.example.com, and fail
   DARA.  However the protocol is set to optional verification with
   "darn=", and so does not report the failure.  The domain specified
   naive.example.com by "darn=" may be useful by spam filters at the
   receiver.  For example the SPF HELO domain may match the "darn="
   domain.

4.  Sender Receiver Co-Signing (SeRCi)








Chuang & Gondwana       Expires 10 November 2023               [Page 13]

Internet-Draft            Replay Resistant ARC                  May 2023


4.1.  Concepts

   We can create a challenge response system using cryptographic signing
   orchestrated between the sender and receiver of an SMTP transaction.
   The receiver challenges the sender to sign a mutually agreed upon
   value with their secret key, and can demonstrate a proof of that SMTP
   client-server relationship to 3rd parties.  One problem is that the
   receiver can't proactively issue the challenge, so as part of the
   EHLO, the server issues the challenge as an optional SMTP extension
   argument.  The sender can respond with the signature incorporating
   the shared value as a SMTP extension verb.  Another problem is
   preventing a malicious party from intercepting a message and trying
   to replicate the challenge.  We propose using a timestamp that can't
   be used in the future i.e. both parties make sure the timestamp
   reasonably represents the current time.  This cryptographic challenge
   needs to sign a hash that ties the signature back to the message, and
   for this proposal, we take the whole message hash from the ARC-
   message-signature.  In addition the destination domain is specified
   to reduce the risk for this signature to be intercepted and reused
   for other communications with other destination domains.

   Such a protocol can help authenticate to a receiver that some sender
   sent a message without risk of replay via some third party.  Sender
   Receiver Co-Signing (SeRCi pronounced Cersei as in the Game-of-
   Thrones character) could be used similarly to SPF [RFC7208] but
   without the risk of shared tenancy attack
   (https://www.7elements.co.uk/resources/blog/smtp-multipass/), IP
   reuse (https://arxiv.org/abs/2204.05122) attack, and BPG
   vulnerabilities (http://people.scs.carleton.ca/~kranakis/Papers/TR-
   05-07.pdf).  Moreover a third party can independently verify the
   result that some sender and receiver sent the given message at the
   given time.  This obviates the need to trust the ARC-Authentication-
   Results.  Later we use SeRCi metadata to describe the forwarding path
   of the message.

   This protocol signs the messages content at the exit to the ADMD to
   protect the SMTP transaction and yet be insensitive to message body
   or header modifications by the ADMD.  This is necessary to tolerate
   the changes that a legitimate forwarder may make such as a mailing
   list adding a footer or adding the name of the mailing list to the
   Subject header.  Other forwarders may alter the Content-Transfer-
   Encoding or delete attachments which this protocol also tolerates.
   However malicious forwarders may add or replace malicious content to
   otherwise benign messages and this must be detected.  SeRCi
   identifies message body changes via different body hashes between the
   originator and the destination.  If a message is unchanged between
   the originator to destination, then malicious content is attributed
   to the originator.  If a message is changed and there is malicious



Chuang & Gondwana       Expires 10 November 2023               [Page 14]

Internet-Draft            Replay Resistant ARC                  May 2023


   content, then the originator and the mutating ADMDs are assigned
   responsibility.  Potentially the attribution can affect the receiver
   reputation given to the ADMDs.  The existing ARC protocol can do
   this, however it is a risky endeavor due to the potential for ARC
   replay and looseness around when ARC does its ARC-Message-Signature.

4.1.1.  SMTP Extension

   The SMTP extension for SeRCi for generating the hash and then
   publishing it, is meant to prove that the sender and receiver
   collaborated to create the hash.  The protocol is advertised as a
   SMTP extension in the SMTP EHLO named SERCI with a timestamp
   argument.  That timestamp will be in UTC seconds.  If the timestamp
   is acceptable to the sender, then it SHOULD sign a tuple of url-safe
   base64 [RFC4648] message hash used in the outbound ARC-Message-
   Signature, destination domain as defined in the next paragraph, and
   timestamp.  (Subsequent base64 operations are assumed to be url-safe
   encoded base64 [RFC4648] to avoid quoted-string) That signature then
   SHOULD be base64 encoded and disclosed to the receiver as:

   SERCI-SIGNATURE <sender domain> <selector> <header-body hash> \
   <message-body hash> <signature>

   where signature is upon a hash of the formatted SeRCi result comment
   string to be presented by the receiver minus the signature.  Note
   there are no white spaces in the hashed string.  To create the
   canonical version whitespace they are removed.  Thus the signature
   is:

   base64(signsender(sha256(<sender domain><selector><header hash>\
   <message body hash><timestamp>)))




















Chuang & Gondwana       Expires 10 November 2023               [Page 15]

Internet-Draft            Replay Resistant ARC                  May 2023


   where domain corresponds to the sender's DKIM domain and selector
   that is used to find the DKIM public key DNS record.  It also
   discloses the header hash and body hash that is used to compute the
   message hash, and are present to allow detection of differences
   between ARC sets.  If the timestamp is not acceptable, the sender can
   report this as SERCI-SIGNATURE "out-of-time" and potentially the
   receiver will return a new timestamp.  The sender is allowed to do
   this once, and after that the receiver MUST report an error.  To
   prevent eavesdropping and potential spoofing, this protocol MUST be
   secured by SMTP TLS.  Upon obtaining the signature, the receiver MUST
   then validate the SeRCi signature.  It looks at the sender's ARC-
   Message-Signature hash to see if that is acceptable, meaning matches
   a hash the receiver generates of the message.  Next it checks if the
   timestamp is the same as provided to the sender, and if the
   destination domain is the same as the receiver's ARC-Seal "d="
   domain.  The SERCI-SIGNATURE command returns OK on success, otherwise
   some error code.

   An example SMTP transaction might look like:

   EHLO sender.example.com
   250-sender.example.com at your service, [1.2.3.4]
   250-SIZE 157286400
   ...
   250 SMTPUTF8
   250 SERCI <timestamp>
   MAIL FROM:<sender>`
   RCPT TO:<recipient>
   DATA <message>
   SERCI-SIGNATURE <sender domain> <selector> \
   base64(<message body hash>) base64(<header hash>) \
   base64(signsender(sha256(<sender domain><selector><header hash> \
   <message body hash><timestamp>)))

4.1.2.  Protocol Awareness

   The sender discovers the receiver's support for this protocol by a
   DNS txt policy lookup upon the recipient email address domain.
   Within this policy record MAY be a tag value indicating which SeRCi
   version number "v=" which MUST be set to "SERCI_1.0" when that ADMD
   indicates it supports SeRCi.  The lookup also discovers the
   normalized destination domain name, and that destination domain MUST
   match the ADMD ARC-Seal "d=" domain [RFC8617] which enables tracing
   this domain _From_ sender to receiver as described later.  The domain
   name is specified "serci=<domain>" in the DNS policy record.  Once
   discovered this domain is put in the sender's ARC-Seal as"
   serci=<domain>", which indicates support by the receiver for the
   SeRCi as well as identify the intended receiver domain.  If no such



Chuang & Gondwana       Expires 10 November 2023               [Page 16]

Internet-Draft            Replay Resistant ARC                  May 2023


   DNS txt policy record is found, then the receiver does not support
   the SeRCi protocol.  This is indicated in the DKIM-Signature or ARC-
   Seal by a SeRCi naive receiver tag/value of "snr=" and _From_ header
   domain for path building described later.  Further the "snr=" tag
   indicates to subsequent SeRCi aware receivers that there was an
   intermediate naive forwarder.  If a domain advertises a SMTP SeRCi-
   SIGNATURE extension but does not publish a DNS txt policy, the sender
   MUST NOT call the SeRCi-SIGNATURE command as the receiver is
   declaring their intent to not participate in SeRCi.  The following is
   an example of a SeRCi aware policy:

   v=SERCI_1.0; serci=example.com

4.1.3.  Receiver Verification

   The SeRCi aware receiver will verify the signature after the SeRCi-
   SIGNATURE verb.  Assuming the receiver agrees with the signature
   (i.e. verifies it), the receiver will add to the ARC-Authentication-
   Result a new authentication-results method "serci" that has a _pass_
   result or _fail_ result otherwise.  It also adds as authentication-
   results [RFC8601] properties, the values needed to contribute to the
   signature verification.  The [RFC8601] ptype is "smtp".  The sender
   domain property is "sd".  The selector is "s".  The message body hash
   is "bh" and the value is encoded in base64.  The header hash is "hh"
   and the value is encoded in base64.  The timestamp is "t".  This is
   illustrated as:

   ARC-Authentication-Results i=1; serci=<pass|fail> (<comment>)
        smtp.sd=<sender domain>
        smtp.s=<sender domain>
        smtp.bh=base64(<message body hash>)
        smtp.hh=base64(<header body hash>)
        smtp.t=<timestamp>
        smtp.s=<selector>
        smtp.b=base64(<signature>)

4.1.4.  Definitions

   DNS TXT Policy tag/values

   *  "v=": Value of "SERCI_1.0" if the ADMD supports the SeRCi
      verification protocol.

   *  "serci=": Value of the receiver's ARC-Seal "d=" domain

   DKIM-Signature or ARC-Seal tag/values





Chuang & Gondwana       Expires 10 November 2023               [Page 17]

Internet-Draft            Replay Resistant ARC                  May 2023


   *  "serci=": Value of the receiver's ARC-Seal "d=" domain when the
      receiver is SeRCi capable found from the SeRCi DNS policy record.

   *  "snr=": Value of RFC822 recipient's domain name when the receiver
      is naive of SeRCi.

   ARC-Authentication-Results method and ptype-properties

   *  "serci=": Value of "pass" if sender/recipient signing validation
      succeeds, otherwise "fail".

   *  "smtp.sd=": sender domain

   *  "smtp.s=": selector

   *  "smtp.bh=": body hash in base64

   *  "smtp.hh=": body hash in base64

   *  "smtp.t=": timestamp in seconds from UTC

   *  "smtp.b=": signature in base64

4.2.  Header Example

  ARC-Seal: i=1; d=destination.example.com
  ARC-Authentication-Results: i=1; serci=pass (comment)
       smtp.sd=originator.example.com smtp.s=selector
       smtp.bh=message_body_hash_base64 smtp.t=1664511950175
       smtp.s=signature_base64
  ARC-Seal: i=1; d=originator.example.com; serci=destination.example.com
  ARC-Authentication-Results: i=1
  To: user@destination.example.com

5.  Relay Flow Identifier

   This specification defines an identifier name for mail traversing a
   relay.  Typically the relay uses password authentication such as
   methods provided for in [RFC4954] but other methods MAY be possible.
   This identifier MAY also be used for authenticated forwarding flows
   such as mailing lists and with other authentication methods such DKIM
   or SPF that verify who the sender is.  Because some traffic may have
   originated at the relay, which traditionally may be DKIM signed, this
   document provides a specification for DKIM [RFC6376].  In other
   instances, the relay forwards traffic originated elsewhere, and these
   are typically not DKIM signed by the relay, so instead this document
   provides a specification using ARC [RFC8617].




Chuang & Gondwana       Expires 10 November 2023               [Page 18]

Internet-Draft            Replay Resistant ARC                  May 2023


   Email Service Providers can delegate relay and forwarding services to
   enterprise customers, typically associated with some customer domain.
   Spammers utilize these features either by acting as an enterprise
   customer or by hijacked accounts.  This specification proposes naming
   flows by enterprise customers to help the email receiver with
   categorization and application of anti-abuse counter measures.  As
   some mechanisms for mail forwarding such as mailing lists are often
   opaque after being sent and problematic for debug and abuse
   protection, this offers a naming scheme to help identify those
   mechanisms.

5.1.  Flow Identification Token

   The relaying service choosing to use this specification MUST
   categorize and name relayed traffic flows such that receivers can do
   anti-abuse analysis upon them if necessary.  In order for the
   identifier to be effective, it SHOULD be persistent in time and
   uniquely named across all flows through the relay.  As relayed
   traffic flow is often associated with a delegated domain, the first
   part of the identifier MUST either include a domain associated url-
   safe base64 [RFC4648] token, or be empty if no such delegated domain
   is present.  It MAY include a local part url-safe base64 [RFC4648]
   token after the domain token and separated by a period '.'.  This
   local part token can help describe the mail forwarding mechanism.
   Combined the domain token and the optional local token form the relay
   flow identifier name.  If a message is associated with more than one
   flow, the relay SHOULD select the more specific flow based on local
   policy.  That name MUST NOT be any relay internal name though MAY be
   a secure cryptographic hash of such.  Also that name MUST NOT contain
   or be associated with any Personally Identifiable Information (PII).
   The parser should ignore commas '+' whose use may be specified in the
   future.

   Example valid names:

   0123456789
   0123456789.abcdwxyz
   .abcdwxyz
   <empty>

5.2.  ARC Authentication-Result Method

   This proposes a new ARC [RFC8617] ARC-Authentication-Result defined
   method [RFC8601] that identifies the presence of a relay flow and its
   property that identifies a relay flow identifier name.  The defined
   method is "relay", which when present, takes a single result value of
   "pass" that indicates the relay was authenticated.  The relay method
   will have a propspec tag-value with a policy ptype with a "rfid"



Chuang & Gondwana       Expires 10 November 2023               [Page 19]

Internet-Draft            Replay Resistant ARC                  May 2023


   property i.e "policy.rfid" that takes a single token value.  That
   token value consists of a domain url-safe base64 token and the
   optional local url-safe base64 token separated by a period.  The
   token parsers MUST ignore a reserved plus that may be further
   specified in the future.

   Example:

   ARC-Authentication-Results: i=1; auth.example.com;
        relay=pass (comments) policy.rfid=0123456789.abcdwxyz

6.  Chain of Custody

   The local results of DARA or SeRCi can be combined into a path of
   verified ADMD domains as defined by the ARC-Seal "d=" domains.  Path
   building can help detect if replay potentially occurred, that is a
   receiver MAY check that a message was forwarded from the originator
   to it with verification errors.  If there are Chain building
   verification errors, then it indicates either there is a protocol
   unaware forwarder, or that there is a malicious sender attempting to
   take the message and reinject it along a new path outside the intent
   of the originator.  A verifier can then check for some prior sender
   DARA declaration of "dara=" vs "darn=", or SeRCi declaration of
   "snr=" vs "serci=" which clarifies definitively which of these aware
   or unaware scenarios applies.  At that point, it is up to the
   receiver's local policy to determine what receiver does with the
   result.  The protocol for this verification is described in more
   detail in subsequent paragraphs.

   The verified path that the message traverses can be used as the
   message flow identifier in a reputation system.  Unlike purely domain
   based reputation systems, a path based one can help differentiate
   benign message flows from malicious ones to help identify replay or
   other abuse by identifying the spammer forwarding malicious content.
   In the Header Examples we describe a scenario where the spammer
   exploits some gullible but otherwise benign intermediate forwarder in
   an attempt to hide their tracks and path based reputation can be
   particularly helpful in uncovering them.

6.1.  Chain Building Algorithm

   The following defines an algorithm for path building using DARA or
   SeRCi identifiers.  We define the nodes of a path as the ARC-Seal
   "d=" identities and who form edges as domain identities pairs.
   Because building the edges of a path is a repeated process across
   edges that are like links, we call this Chain of Custody building or
   Chaining for short.  It starts at the destination at ARC set "i=N",
   and walks through the ARC headers to the originator ARC set "i=1" or



Chuang & Gondwana       Expires 10 November 2023               [Page 20]

Internet-Draft            Replay Resistant ARC                  May 2023


   the DKIM-Signature.  The edge is defined as a pair of nodes (_d_N_ ,
   _d_(N-1)_) where the sender's "dara=" or "serci=" domain is _d_N_ and
   the receiver's ARC-Seal "d=" domain _d'_N_ MUST match.  If so, edge
   building considers this a local _pass_.  If the "dara=" or "serci="
   result is missing, the verifier checks if there is instead a
   corresponding "darn=" or "snr=" tag at this or prior ARC set, then
   specifies an edge result of _neutral_, otherwise as _fail_.  Next the
   receiver's ARC-Set number MUST be "i=N-1" and if so then the ARC-Seal
   "d=" domain is defined as _d_(N-1)_.  This recursively is extended
   for (_d_(N-1)_ , _d_(N-2)_) i.e. for ARC set "i=N-2" and so forth for
   each "i=n" to _d_1_.








































Chuang & Gondwana       Expires 10 November 2023               [Page 21]

Internet-Draft            Replay Resistant ARC                  May 2023


   Local Chain verifier is done for each ARC set n following the above
   edge building from "i=N" to "i=1" and builds two vectors.  One vector
   keeps the local chain results and the other ARC-Seal "d=" domains.
   The verifier assumes that results from ARC header and message-body
   signature verification, SeRCi or DARA verifications have already run
   and the results already populate the ARC-Authentication-Results.  For
   ARC set "i=N" to ARC set "i=2", the verifier MUST evaluate the local
   result, meaning the ARC result (i.e. from ARC seal verification and
   sometime ARC message-signature verification), edge building result,
   and DARA or SeRCi verification result.  If either of them _pass_, the
   local Chain result is _pass_.  Otherwise if any of them are _neutral_
   or SeRCi is _softfail_, and the rest pass, the result is _neutral_.
   Otherwise the result is _failure_.  Further local policy MAY modify
   the ARC message-signature result (perhaps due to future work around
   this draft (https://datatracker.ietf.org/doc/draft-kucherawy-dkim-
   transform/) or this one (https://datatracker.ietf.org/doc/draft-
   kucherawy-dkim-list-canon/)) We recommend with the Chaining protocol
   to continue verification even if the sender's Chain result is failure
   or neutral, to provide forensics evidence for subsequent receivers.
   Receivers SHOULD independently match the DARA recipients and verify
   SeRCi signature rather than taking the result from ARC-
   Authentication-Result and having to trust an externally generated
   result.  At the originator's ARC set "i=1" corresponding to _d_1_ or
   DKIM-Signature corresponding to _d_0_ the verifier first verifies
   alignment between header _From_ domain and the ARC-Seal "serci="
   domain.  That domain defines _d_1_ or _d_0_ and the verifier looks up
   the SeRCi policy associated with the domain which MUST exist.  If
   they are not aligned, then the local Chain verification is considered
   _neutral_ as the message may have been was forwarded to some unaware
   domain.  In addition the ARC seal validation for origination MUST
   _pass_ or local Chain verification is considered _fail_.  Once these
   checks pass, then Chain building for "i=1" is considered to pass.
   The local Chain results is added onto the result vector at that index
   for all indexes, and similarly the ARC-Seal "d=" domain onto the
   domain vector.  If relay flow identifier is available for that ARC
   set, the relay flow identifier may be used instead of the domain per
   local policy.

   To compute the global Chain result, there is a walk over the vector
   of results.  The global Chain result is initialized to _pass_.
   Starting from "i=N" index to "i=1", if the local result is _fail_
   then the global result is _fail_, else if local result is _neutral_
   then the global is _neutral_.  If the local result is _fail_, then
   the domain result is cleared from that index to i=1.  This will
   attempt to extend the domain list by looking at the prior ARC sets
   SPF result.  If that has a SPF _pass_, then the SPF domain is placed
   in that index, otherwise this inserts a failure indication with the
   cause e.g. "arc-fail" at that index.  If there are multiple failures,



Chuang & Gondwana       Expires 10 November 2023               [Page 22]

Internet-Draft            Replay Resistant ARC                  May 2023


   this chooses the most specific error as the cause e.g "serci-fail"
   over "arc-fail".  This then truncates cleared domain entries from the
   domain list.  If the local result is _fail_, this walk halts.  If the
   local result is _neutral_, and there is a "snr=" or "darn=" then this
   inserts the domain in the domain list after the current index which
   helps identify it in the constructed path.  A synthetic _neutral
   _result is also inserted in the result path.  This also similarly
   extends the path when "i=1" and the message doesn't originate at that
   domain (missing alignment between the _From_ header domain and ARC-
   Seal "d=" domain) to better identify the flow.  If so and the SPF
   result is a _pass_, this prepends the SPF domain and synthetic result
   into the respective vectors.  If there is a non-passing SPF result,
   this prepends a SPF status string such as "spf-neutral" to the domain
   vector and the status to status vector.  The global Chain result is
   published ARC-Authentication-Results as a "chain=".  result.  If the
   result is _pass_, then the message is considered to be
   _authenticated_ by SeRCi, otherwise _unauthenticated_.

6.2.  Modified Body Algorithm

   The protocol can detect when a message is modified along the
   forwarding path by looking at the current and previous message body
   hash and comparing them to find for changes.  If the message content
   is considered spammy and phishy, then ADMDs that may have contributed
   to that problematic message body content will have their reputation
   per domain reputation of ADMDs negatively reduced.  Other ADMDs that
   are proven to not have contributed message content SHOULD NOT be
   affected.  A per domain reputation sensitive to message modification
   is useful when the path based reputation has not been established,
   and instead the per domain reputation can initialize the reputation
   of the sender.  For this we keep a reputation table indexed by
   domains.  We collect the domains that modify the messages in a
   forwarding path including the sender, and update their reputation
   collectively and equally based on the spam and phishing scores.
   Alternatively the path identifier can be further specialized by
   adding an indicator whether a forwarding ADMD modified the message.
   That differentiates path sensitive reputation by whether a forwarder
   modified the message or not.

6.3.  Definitions

   ARC-Authentication-Results tags

   *  "chain=": Value of _pass_ if local results and prior nodes are all
      passes, otherwise if "snr=" was present in the flow then
      _neutral_, else _fail_.





Chuang & Gondwana       Expires 10 November 2023               [Page 23]

Internet-Draft            Replay Resistant ARC                  May 2023


7.  Chaining Header Examples

   The following two examples illustrate working SeRCi/Chain-Building
   verification.  This is followed by an example of DKIM replay attack.
   The second to last example is illustrative of how this protocol
   behaves with a SPF upgrade attack.  The last example demonstrates a
   modified message body by a forwarder.  (Other examples do not have a
   forwarder that modifies the message) .

7.1.  Originator ==> Mailing-List ==> Receiver

   This is an example of mail being sent from one Mail-Box-Provider to
   another through a Mailing-List where all ADMDs participate in SeRCi.
   In this illustrative example, we show the construction of the
   headers.

   Originator (after ARC seal)

   ARC-Seal: i=1; d=originator.example.com;
       serci=mailinglist.example.com
   ARC-Authentication-Results: i=1
   To: mailing.list@mailinglist.example.com

   Mailing-List outbound (after ARC seal)

   ARC-Seal: i=2; d=mailinglist.example.com;
       serci=destination.example.com
   ARC-Authentication-Results: i=2; serci=pass; chain=pass
   ARC-Seal: i=1; d=originator.example.com;
       serci=mailinglist.example.com
   ARC-Authentication-Results: i=1
   To: mailing.list@mailinglist.example.com

   Receiver inbound (after ARC seal)

   ARC-Seal: i=3; d=receiver.example.com
   ARC-Authentication-Results: i=3; serci=pass; chain=pass
   ARC-Seal: i=2; d=mailinglist.example.com;
       serci=destination.example.com
   ARC-Authentication-Results: i=2; serci=pass; chain=pass
   ARC-Seal: i=1; d=originator.example.com;
       serci=mailinglist.example.com
   ARC-Authentication-Results: i=1
   To: mailing.list@mailinglist.example.com







Chuang & Gondwana       Expires 10 November 2023               [Page 24]

Internet-Draft            Replay Resistant ARC                  May 2023


   The global Chain verification result is _pass_ and the message is
   considered SeRCi _authenticated_.  The constructed path is
   [originator.example.com, mailinglist.example.com,
   receiver.example.com].

7.2.  Originator ==> Naive-Forwarder ==>Aware-Forwarder ==>Aware-
      Receiver

   This demonstrates a naive forwarder naive.example.com that does not
   support SeRCi/Chain.  The headers represent what would be seen after
   inbound delivery to the receiver.

   ARC-Seal: i=3; d=receiver.example.com
   ARC-Authentication-Results: i=3; serci=pass; chain=neutral
   ARC-Seal: i=2; d=intermediate.example.com;
       serci=receiver.example.com
   ARC-Authentication-Results: i=2; chain=neutral
   ARC-Seal: i=1; d=originator.example.com; snr=naive.example.com
   ARC-Authentication-Results: i=1
   To: user@naive.example.com

   The global Chain verification result is _neutral_ and the message is
   considered SeRCi _unauthenticated_.  The constructed path is
   [originator.example.com, naive.example.com, intermediary.example.com,
   receiver.example.com].

7.3.  Originator ==> Receiver ; Spammer ==> Victim Receiver

   Headers as seen by the receiver ADMD.

   ARC-Seal: i=2; d=receiver.example.com
   ARC-Authentication-Results: i=2; serci=pass; chain=pass
   ARC-Seal: i=1; d=originator.example.com;
       serci=receiver.example.com
   ARC-Authentication-Results: i=1
   To: user@receiver.example.com

   Final headers as seen by the victim ADMD after replay injection to
   victim.example.com domain.

   ARC-Seal: i=3; d=victim.example.com
   ARC-Authentication-Results: i=3; chain=fail
   ARC-Seal: i=2; d=receiver.example.com
   ARC-Authentication-Results: i=2; serci=pass; chain=pass
   ARC-Seal: i=1; d=originator.example.com;
       serci=receiver.example.com
   ARC-Authentication-Results: i=1
   To: user@receiver.example.com



Chuang & Gondwana       Expires 10 November 2023               [Page 25]

Internet-Draft            Replay Resistant ARC                  May 2023


   Note at ARC set #2, it does not set a "serci=" tag, causing a path
   discontinuity.  Due to the path discontinuity, the global Chain
   verification result is _fail_ and the message is considered SeRCi
   _unauthenticated_.  The constructed path is [serci-fail].

7.4.  Spammer ==> Gullible Forwarder ==> Receiver

   In this example the spammer does not participate in ARC or SeRCi/
   Chain protocol.  The spammer forwards a message through an permissive
   cloud provider gullible.forwarder.com to reach the inbox of some user
   at desination.example.com.  Spammer selects a victim domain that uses
   email services of gullible.forwarder.com such that they include the
   IPs of gullible.forwarder.com in their SPF policy.  While the spammer
   cannot SPF authenticate at inbound to gullible.forwarder.com, they
   can SPF authenticate at inbound to destination.example.com, hence the
   SPF upgrade attack.

   ARC-Seal: i=2; d=receiver.example.com
   ARC-Authentication-Results: i=2; spf=pass; serci=pass; chain=pass
   ARC-Seal: i=1; d=gullible.example.com;
       serci=receiver.example.com
   ARC-Authentication-Results: i=1; spf=neutral
   To: user@guillible.example.com
   From: spoofed_user@victim.example.com

   While SPF and consequently DMARC is _pass_ at the receiver, SeRCi/
   Chain verification result is _neutral_ because the message was not
   originated at victim.example.com.  A DMARC evaluation would likely
   pick the SPF result.  Instead a better approach might be to use the
   path based reputation system.  The spammy forwarding path is [spf-
   neutral, gullible.example.com, receiver.example.com] which include
   evidence of the spammer.  Contrasts that to the path from a normal
   message delivery by victim.example.com using their cloud provider
   which either would look like [victim.example.com,
   receiver.example.com] or [victim.example.com, gullible.example.com,
   receiver.example.com].  Both would be distinct from the spammer
   forwarding flow in a path aware reputation system.

   The spammer may attempt to confuse the receiver by replaying ARC
   headers before forwarding to gullible.forwarder.com.  This would
   change the SeRCi/Chain verification result to _fail_ and the
   constructed path very much [arc-fail, gullible.example.com,
   destination.example.com].  As gullible.forwarder.com is ARC and SeRCi
   aware, it would indicate that the replayed ARC headers would not pass
   ARC verification.






Chuang & Gondwana       Expires 10 November 2023               [Page 26]

Internet-Draft            Replay Resistant ARC                  May 2023


7.5.  Originator ==> Modifying Forwarder ==> Receiver

   This demonstrates a spammy message where the forwarder modifies the
   message content, representing for example a mailing list adding a
   footer.

   ARC-Seal: i=3; d=receiver.example.com
   ARC-Authentication-Results: i=3; serci=pass; chain=neutral
   ARC-Seal: i=2; d=intermediary.example.com;
       serci=destination.example.com
   ARC-Authentication-Results: i=2; chain=pass
   ARC-Seal: i=1; d=originator.example.com;
       serci=intermediary.example.com
   ARC-Authentication-Results: i=1
   To: user@receiver.example.com

   While the global Chain verification result is _pass_ and the message
   is considered SeRCi _authenticated_, the modified message body change
   is visible via the modified body algorithm.  The constructed path is
   [originator.example.com, modified-message-body,
   intermediary.example.com, receiver.example.com] where we embellish
   the path with the modification result.  The set of contributing
   domains associated with the spammy message is
   {originator.example.com, intermediary.example.com}.

   A different message may travel along the same forwarding path but is
   not modified by the forwarder.  That non-modifying forwarder
   constructed path is: [originator.example.com,
   intermediary.example.com, destination.example.com], and is distinct
   from above.  The set of contributing domains associated with the
   message content is now {originator.example.com}.

7.6.  Spammer ==> Relay ==> Receiver

   This demonstrates a spammer sending a message through a relay to
   receiver.

   ARC-Seal: i=2; d=receiver.example.com
   ARC-Authentication-Results: i=2; spf=pass; serci=pass; chain=pass
   ARC-Seal: i=1; d=relay.forwarder.com;
       serci=destination.example.com
   ARC-Authentication-Results: i=1; spf=neutral; relay=pass
       policy.rfid=relay+flow+id
   To: user@receiver.example.com
   From: spoofed_user@victim.example.com






Chuang & Gondwana       Expires 10 November 2023               [Page 27]

Internet-Draft            Replay Resistant ARC                  May 2023


   As with the above, a better approach might be to use the path based
   reputation system where the relay flow identifier is used to replace
   the domain in the path .  The spammy forwarding path is [spf-neutral,
   relay+flow+id, receiver.example.com].  Reputation analysis using this
   identifier with the relay flow identifier will be more specific than
   the domain based approach.

8.  DMARC

   These protocols can act as authenticators for DMARC [RFC7489].  As
   noted in the Chain of Provenance section, the From header domain can
   be aligned with the DKIM-Signature d= domain or the ARC-Seal "d="
   domains at ARC set "i=1" at the Originator.  Assuming From alignment,
   and a chain building with either DARA or SeRCi has a global pass,
   this indicates a DMARC pass.  As noted in the prior example, when
   available SeRCi/Chain can provide more accurate authentication than
   SPF or DKIM, and it is up to local policy to determine preferencing
   or exclusion of results.

9.  Privacy Considerations

   The DARA techniques depend upon declaring all recipients into the
   mail headers, and signing them.  This could leak who the other
   recipients are with Bcc and mailing list recipients, for whom other
   recipients are hidden.  To prevent this information leakage, the
   message must be duplicated for each hidden recipient and uniquely
   signed.

10.  Security Considerations

11.  IANA Considerations

   This document has no IANA actions yet.

12.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4648>.







Chuang & Gondwana       Expires 10 November 2023               [Page 28]

Internet-Draft            Replay Resistant ARC                  May 2023


   [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,
              <https://www.rfc-editor.org/rfc/rfc4954>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <https://www.rfc-editor.org/rfc/rfc5598>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/rfc/rfc6376>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/rfc/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/rfc/rfc7489>.

   [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 8601,
              DOI 10.17487/RFC8601, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8601>.

   [RFC8617]  Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
              Kucherawy, Ed., "The Authenticated Received Chain (ARC)
              Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8617>.

Appendix A.  Acknowledgments

   Thanks goes to Emanuel Schorsch and Bruce Nan, Brandon Long, John R.
   Levine, and Murray S.  Kucherawy for their knowledgeable feedback.
   Many thanks also to Marc Bradshaw for his contributions to concepts
   of authenticating senders.



Chuang & Gondwana       Expires 10 November 2023               [Page 29]

Internet-Draft            Replay Resistant ARC                  May 2023


Authors' Addresses

   Weihaw Chuang
   Google, Inc.
   Email: weihaw@google.com


   Bron Gondwana
   Fastmail Pty Ltd
   Email: brong@fastmailteam.com









































Chuang & Gondwana       Expires 10 November 2023               [Page 30]