Independent Stream W. Chuang Internet-Draft Google, Inc. Intended status: Experimental B. Gondwana Expires: 14 February 2024 Fastmail Pty Ltd 13 August 2023 Replay Resistant Authenticated Receiver Chain draft-chuang-replay-resistant-arc-09 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 a replay resistant cryptographic based protocol that discloses all SMTP recipients and signs them, allowing a receiver or any third party to verify that the message went to the intended recipient. If not then then potentially the message is replayed. Moreover it leverages ARC (RFC8617) and sender defined forwarding path to build a "chain of custody" that accurately defines the SMTP forwarding path of the message. This also allows the protocol to detect DKIM and ARC replay attacks and other attacks. 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." This Internet-Draft will expire on 14 February 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Chuang & Gondwana Expires 14 February 2024 [Page 1] Internet-Draft Replay Resistant ARC August 2023 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 . . . . . . . . . . . . . . . . . . . . . . 4 2. Defining and Propagating Sender Identity in Mail Flow . . . . 5 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. Chain of Custody . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Chain Building Algorithm . . . . . . . . . . . . . . . . 15 4.2. Modified Body Algorithm . . . . . . . . . . . . . . . . . 16 4.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.1. Originator ⇒ Mailing-List ⇒ Receiver . . . . . . . . 17 4.4.2. Originator ⇒ Mailing-List (From rewrite) ⇒ Receiver . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3. Originator ⇒ Naive-Forwarder ⇒Aware-Forwarder ⇒Aware-Receiver . . . . . . . . . . . . . . . . . . . 19 4.4.4. Originator ⇒ Receiver ; Spammer ⇒ Victim Receiver . . 19 5. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Parked Material . . . . . . . . . . . . . . . . . . 22 Chuang & Gondwana Expires 14 February 2024 [Page 2] Internet-Draft Replay Resistant ARC August 2023 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22 B.2. Sender Receiver Co-Signing (SeRCi) . . . . . . . . . . . 23 B.2.1. Concepts . . . . . . . . . . . . . . . . . . . . . . 23 B.2.2. Header Example . . . . . . . . . . . . . . . . . . . 27 B.3. Relay Flow Identifier . . . . . . . . . . . . . . . . . . 27 B.3.1. Flow Identification Token . . . . . . . . . . . . . . 28 B.3.2. ARC Authentication-Result Method . . . . . . . . . . 28 B.3.3. Spammer ⇒ Relay ⇒ Receiver . . . . . . . . . . . . . 29 B.3.4. Spammer ⇒ Gullible Forwarder ⇒ Receiver . . . . . . . 29 B.3.5. Originator ⇒ Modifying Forwarder ⇒ Receiver . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This protocol provides a technique to authenticate email by domain that is replay resistant. It leverages the features of ARC to name ADMD in the email forwarding path and to publish the intermediate results. It then discloses all SMTP recipients as signed RFC822 headers by the sender which allows a receiver to verify if the mail was directed to the appropriate recipient. The results 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. Existing email authentication techniques have known limitations. DKIM suffers from being vulnerable to replay attacks as described in draft-ietf-dkim-replay-problem (https://datatracker.ietf.org/doc/ draft-ietf-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. The broader goals of this internet-draft 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. Chuang & Gondwana Expires 14 February 2024 [Page 3] Internet-Draft Replay Resistant ARC August 2023 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-ietf-dkim-replay-problem (https://datatracker.ietf.org/doc/draft-ietf-dkim-replay-problem/) adds context to those mailflows for the DKIM replay problem. 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. Chuang & Gondwana Expires 14 February 2024 [Page 4] Internet-Draft Replay Resistant ARC August 2023 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. 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 sections. This protocol leverages ARC and DKIM for declaring protocol settings and protecting the integrity of the headers and message body, and ARC for propagating authentication results. At message origination, this uses DKIM-Signature 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. This protocol updates ARC-Authentication-Results with new method status, properties and comments as defined in Section 3. This protocol identifies and names the ADMDs by the signer domain as defined in the DKIM-Signature "d=" or ARC-Seal "d=". The traversed MAIL FLOW forwarding path is defined as a vector of these domains, and is further defined in Section 4. This specification mandates that the ADMDs participating in this protocol explicitly identify themselves with a DKIM-Signature or ARC- Seal tags "dara" or "darn". At the originating sender, participants MAY declare participation with a tag in the DKIM-Signature if the recipient declaration and signing as described later is covered by To and Cc, otherwise they MUST declare with a tag in the ARC-Seal. Later this document will describe when to use Forwarded-to header which is protected by the ARC-Seal. Additionally if the message is forwarded, participation MUST be declared in a tag in the ARC-Seal. Participants will declare an identified path of ADMD nodes from the originating sender ADMD to the receiving ADMD with the "dara" tag. If the message exits the identified path into some naive, protocol unaware ADMD the aware ADMD denotes this using the "darn" tag, allowing for mitigations for this scenario. The tags and their use are further specified in Section 3.1.2. Chuang & Gondwana Expires 14 February 2024 [Page 5] Internet-Draft Replay Resistant ARC August 2023 This protocol REQUIRES that the _From_ header domain MUST align with DKIM-Signature "d=" domain or ARC-Seal "d= domain at the starting ADMD in the mail flow path thereby ties the From identity to the cryptographic signer. This allows any receiver or third party to verifiably determine that the message was sent by the signer. This ADMD defines the MSA ADMD, i.e. the responsible originating sender. Some forwarders such as mailing-lists modify the message and to prevent DMARC misalignment, they resign the message with their own DKIM signature and rewrite the From header aligned to their domain. From header rewriting hinders discovering the original sender. As this protocol is insensitive to message message modification, forwarders using this protocol MAY choose not to From header rewrite or resign the message with DKIM when they detect the receiver supports this protocol. Non-normatively receivers might consider applying methods to recover the originating sender's From header by using methods such as draft-chuang-mailing-list-modifications (https://datatracker.ietf.org/doc/draft-chuang-mailing-list- modifications/). If the originating sender performs ARC signing, the ARC the ARC- Authentication-Results MUST be empty as results will otherwise be non-sensical. When the message is delivered to the inbox by the MDA, 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-Seals and ARC-Message-Signatures but containing ARC-Authentication-Result has been delivered to the inbox. Seeing such a message in delivery may be replayed and is denoted by an ARC verification _fail_ status. This protocol protects against malicious use of these ARC headers by REQUIRING message signing and verification between ADMDs. In addition there MAY be ARC signing and verification 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 ARC-Seal signature from "i=N" (receiver's ARC set number) to "i=1" (originating sender or first forwarder) as well as the presence of all headers in the ARC set as defined in [RFC8617]. If the receiver sees a verification failure from the immediate sender's "i=N-1" ARC-Message-Signature, this MUST result in an ARC verification _fail_ status. ARC-Message-Signature verification failures from "i=N-2" to "i=1" are tolerated, meaning their failure does not indicate a failing ARC result e.g. mailing-list modification. All ARC-Seal verification failures from "i=N-1" to "i=1" are treated as ARC verification _fail_ status. The result of the verification is published in the Authentication-Result and the Chuang & Gondwana Expires 14 February 2024 [Page 6] Internet-Draft Replay Resistant ARC August 2023 ARC-Authentication-Result with a tag "arc=". Even if the receiver notes that a prior receiver publishes a ARC verification fails, this specification asks the receiver to continue ARC generation and verification to provide forensics evidence via the ARC- 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 email authentication protocol uses validating signed headers against the envelope headers. It features a looks 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 The specified email authentication protocol is 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. When To: and Cc: recipients are declared by their headers, they MUST be specified in the "h=" header list and signed by DKIM-Signature or ARC-Message-Signature. For blind carbon copy, while a Bcc: header might 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. It MAY include one or more comma separated recipients. Whitespaces in the recipient list are ignored. Forwarded-to: i=1; user@example.com, user2@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 Chuang & Gondwana Expires 14 February 2024 [Page 7] Internet-Draft Replay Resistant ARC August 2023 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 a prior _Forwarded-to_ MAY elect to optimize header space by skipping adding a redundant _Forwarded-to_ header. To protect the integrity of the _Forwarded-to:_ header, they MUST be hashed and signed by ARC-Message-Signature as follows: Collect all _Forwarded-to:_ headers and hash them following the header processing algorithm in [RFC6376] section 5.4. This hash is published in the ARC-Message-Signature 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 as well as the _To:_ and _Cc:_ headers. For example: ARC-Message-Signature: i=1; fh=abcd... Forwarded-to: user@example.com If the originating sender uses a DKIM-Signature, the To and Cc headers MUST be present in the sender's DKIM-Signature, and signed. 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 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. All ADMD supporting the DARA protocol SHOULD publish a DNS TXT policy record. The DARA aware sender SHOULD look up the receiver's policy record as described next or look up an internal list of receivers that support DARA. The following paragraph describes the DARA DNS policy record and disclosure statement, and the following paragraph describes when the ADMD does not support DARA. When the ADMD indicates it supports DARA via DNS, the ADMD publishes a DNS TXT policy record at the supported domain name, prepended with a "_dara" label. The format of the policy record are tag/values in form of the textual representation in [RFC6376] section 3.2. The policy record MUST start with a DARA version tag "v=" with a DARA version number that MUST be set to "DARA_1.0". The lookup also discovers the destination domain name, and that destination domain MUST match the ADMD's ARC-Seal "d=" signing domain [RFC8617] which Chuang & Gondwana Expires 14 February 2024 [Page 8] Internet-Draft Replay Resistant ARC August 2023 enables tracing this domain _From_ sender to receiver as described later. The signing domain name is specified by the tag "dara=" with value being that domain name. The "dara=" signing domain enables an Email Service Provider (ESP) to forward mail on behalf of someone else. Once discovered, this domain is copied to "dara=" domain that is then placed in the sender's DKIM-Signature or ARC- Seal. The "dara=" tag/value indicates support by the receiver for the DARA as well as the identity of the intended receiver signing domain. The following is an example of a DARA DNS policy record for example.org that normalizes to example.com. The TXT record is published at __dara.example.org_ and contains: v=DARA_1.0; dara=example.com If no such DNS TXT policy record is found or not in the list of supported domains, then the receiver does not support the DARA protocol. This is indicated by the tag "darn=" with the receiving domain as the value. This is placed in the sender's DKIM-Signature or ARC-Seal. 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 malicious forwarder was acting as a Man-In-The-Middle and has stripped off some prior sender's DARA policy. If it detects a DARA declaration in the sender's DNS policy, but not declared 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 present) using the ARC set number to determine recency. If not present then it looks for a DKIM-Signature. When found, a DARA aware receiver verifies the integrity of the 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 might be replayed. The recipient verification process for a given forwarder is to collect all the recipients in the _To_, _Cc_ and prior _Forwarded-to_ headers. In particular, for a forwarder i=n, the verifier collects all Forwarded- to headers from i=1 to i=n-1. It verifies that they are signed appropriately and if not fails the verification. If the message only contains a DKIM-Signature, the verifier checks that the To and Cc headers are present in the DKIM-Signature "h=" header list, and Chuang & Gondwana Expires 14 February 2024 [Page 9] Internet-Draft Replay Resistant ARC August 2023 signed. Otherwise it checks for the presence of the "fh=" tag in the ARC-Message-Signature. Next it checks the integrity of the Forwarded-to headers by validating the "fh=" hash if present. The receiver collects all _To:_, _Cc:_ and_ Forwarded-to:_ headers and hash them following the header processing algorithm in [RFC6376] section 5.4, then checks the hash against the value associated with the "fh=" tag. If this mismatches, this is treated as failing verification. Assuming headers integrity, 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. If not a subset, this too is treated as failing verification. As with other email authentication methods, the receiver's verifier is free to apply a locally defined policy against unauthenticated email. Next if the sender's tag is "dara=", the verifier SHOULD treat validation success as _pass_, and validation failure as _fail_. If the sender' tag is "darn=", the verifier SHOULD treat recipient verification failure as _neutral_ and SHOULD treat success as _pass_. This discretionary validation mode is to support the scenario of DARA unaware ADMDs that may cause false positive validation failures. The domain value associated with the "darn=" tag helps identify the naive ADMD in processing local policy. After the receiver's verifier applies the "dara=" or "darn=" policy as described above, the result of this verification MUST be published in the ARC-Authentication-Results. The verifier describes the result with [RFC8601] method "dara", and a result value of _pass_, _fail_ or _neutral_. Receivers MUST declare the RCPT TO identity of that the message was received as a property header.i=. 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 results from the sender and receiver using only values in the message headers and DNS. First the verifier identifies the sender and receiver. The sender may be identified by ARC-Seal with an ARC set number preceding the receiver or DKIM-Signature if no prior ARC-Seal is discovered. The sender's "dara=" or "darn=" policy declaration in the ARC-Seal or DKIM-Signature. The receiver's results will be found in the ARC- Authentication-Results. For both the sender and receiver, the integrity of the headers are checked i.e. checking the ARC-Seal and then the "fh=" hash. If it passes, then verifier determines the Chuang & Gondwana Expires 14 February 2024 [Page 10] Internet-Draft Replay Resistant ARC August 2023 sender's declaration of the receiver's DARA support, by looking for "dara=" tag in the DKIM-Signature or ARC-Message-Signature. 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_. The above procedure can later be used by the Chain verification algorithm in Section 4 to construct verification across multiple senders and receivers in the mail flow. 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 as 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) Chuang & Gondwana Expires 14 February 2024 [Page 11] Internet-Draft Replay Resistant ARC August 2023 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) Forwarded-to: i=1; user@receiver.example.org ARC-Seal: i=1; d=mailinglist.example.com... ARC-Message-Signature: i=1; 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... ARC-Message-Signature: i=2; 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... ARC-Message-Signature: i=1; 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) Chuang & Gondwana Expires 14 February 2024 [Page 12] Internet-Draft Replay Resistant ARC August 2023 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) 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 through Bcc to a forwarder that does not support DARA. First outbound (after ARC seal) ARC-Seal: i=1; d=originator.example.com; darn=naive.example.com; ARC-Message-Signature: i=1; fh=... Forwarded-to: i=1; user@naive.example.com Bcc: user@naive.example.com 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.example.com supports DARA. Final inbound (after ARC seal). Chuang & Gondwana Expires 14 February 2024 [Page 13] Internet-Draft Replay Resistant ARC August 2023 ARC-Seal: i=2; d=aware.example.com ARC-Authentication-Results: i=2; dara=neutral header.i=user@aware.example.com (rcpt.to user@aware.example.com mismatches signed header); ARC-Seal: i=1; d=originator.example.com; darn=naive.example.com; ARC-Message-Signature: i=1; fh=... Forwarded-to: i=1; user@naive.example.com Bcc: user@naive.example.com 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. Chain of Custody The local results of DARA can be combined into a path of verified ADMD domains from the originating sender to the receiver. As noted earlier, the ADMD are defined by the ARC-Seal "d=" domains with FROM header alignment ADMD as the originating sender. The sender-defined receivers are described by the "dara=" tag at the sender containing the receiving domains and create sender-receiver pairs or metaphorical link in a chain. The originating sender defines the provenance of the message and the connected pairs create a "Chain of Custody" of the message. Chain building and verification can help detect if replay potentially occurred when there is a verification error. More specifically, a validation error can indicate there is a protocol unaware forwarder, or there is a malicious sender attempting to take the message and reinject it along a new path outside the intent of the originating sender. The verifier can check the prior sender's DARA declaration of "darn=" vs "dara=" to determine whether the unaware but benign scenario applies, or the aware sender but malicious scenario applies. If the malicious scenario, then 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. Chuang & Gondwana Expires 14 February 2024 [Page 14] Internet-Draft Replay Resistant ARC August 2023 4.1. Chain Building Algorithm The following defines an algorithm for path building using DARA identifiers. We define the nodes of a path as the ARC-Seal "d=" identities and whose edges are sender-receiver 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 originating sender's ARC set "i=1" or the DKIM-Signature. The edge is defined as a pair of nodes (_d_(n-1)_ , _d_n_) where the sender's ARC instance number "i=n-1" and receiver's "i=n". Further "_d_(n-1)_=" is the sender's ARC-Seal "d=" domain, and "_d_n_=" is the receiver's ARC-Seal "d=" domain. Next the sender's "dara=" domain _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=" result is missing, the verifier checks if there is instead a corresponding "darn=" tag at this or prior ARC set, then specifies an edge result of _neutral_, otherwise as _fail_. This recursively is extended for (_d_(N-2)_ , _d_(N-1)_) i.e. for ARC set "i=n-2" and so forth for each n instance number to 1. At instance number 1, the verifier attempts to extend to a DKIM- Signature that is From header aligned and contains a "dara=" tag. If so, the DKIM-Signature is treated as a virtual "i=0", and the verifier checks if the DKIM-Signature "dara=" domain matches the ARC- Seal i=1 "d=" domain. 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, 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 verification result. If it _passes_, the local Chain result is _pass_. Otherwise if any of them are _neutral_ 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 draft-kucherawy-dkim- transform (https://datatracker.ietf.org/doc/draft-kucherawy-dkim- transform/) or draft-chuang-mailing-list-modifications (https://datatracker.ietf.org/doc/draft-chuang-mailing-list- modifications/)) 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 determine if the DARA header.i recipients from the ARC-Authentication-Result header is a subset of the declared and Chuang & Gondwana Expires 14 February 2024 [Page 15] Internet-Draft Replay Resistant ARC August 2023 signed recipients. At the originating sender'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 "dara=" domain. That domain defines _d_1_ or _d_0_ and the verifier looks up the DARA 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 forwarded from 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. To compute the global Chain result, the verifier walks 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 inserts a failure indication e.g. "arc-fail" at that index. If there are multiple failures, this chooses the most specific error as the cause e.g "dara-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 "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. The global Chain result is published ARC-Authentication-Results as a "chain=". If the result is _pass_, then the message is considered to be _authenticated_ by DARA, otherwise _unauthenticated_. 4.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 MAY have their reputation per domain reputation of ADMDs negatively impacted. Other ADMDs that are proven to not have contributed message content SHOULD NOT be affected. Chuang & Gondwana Expires 14 February 2024 [Page 16] Internet-Draft Replay Resistant ARC August 2023 4.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_. 4.4. Examples The following two examples illustrate working DARA/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) . 4.4.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 DARA. In this illustrative example, we show the construction of the headers. Originator (after ARC seal) ARC-Seal: i=1; d=originator.example.com; dara=mailinglist.example.com ARC-Authentication-Results: i=1 From: user@originator.example.com To: mailing.list@mailinglist.example.com Mailing-List outbound (after ARC seal) ARC-Seal: i=2; d=mailinglist.example.com; dara=destination.example.com ARC-Authentication-Results: i=2; dara=pass; chain=pass ARC-Seal: i=1; d=originator.example.com; dara=mailinglist.example.com ARC-Authentication-Results: i=1 From: user@originator.example.com To: mailing.list@mailinglist.example.com Receiver inbound (after ARC seal) Chuang & Gondwana Expires 14 February 2024 [Page 17] Internet-Draft Replay Resistant ARC August 2023 ARC-Seal: i=3; d=receiver.example.com ARC-Authentication-Results: i=3; dara=pass; chain=pass ARC-Seal: i=2; d=mailinglist.example.com; dara=destination.example.com ARC-Authentication-Results: i=2; dara=pass; chain=pass ARC-Seal: i=1; d=originator.example.com; dara=mailinglist.example.com ARC-Authentication-Results: i=1 From: user@originator.example.com To: mailing.list@mailinglist.example.com The global Chain verification result is _pass_ and the message is considered DARA _authenticated_. The constructed path is [originator.example.com, mailinglist.example.com, receiver.example.com]. 4.4.2. Originator ⇒ Mailing-List (From rewrite) ⇒ 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 DARA. In this illustrative example, we show the construction of the headers. Originator (after ARC seal) DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com From: user@originator.example.com To: list@mailinglist.example.com Mailing-List outbound (after ARC reseal) Forwarded-to: i=1; user@receiver.example.org ARC-Seal: i=1; d=mailinglist.example.com... ARC-Message-Signature: i=1; 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=mailinglist.example.com; dara=receiver.example.org From: user@mailinglist.example.com To: list@mailinglist.example.com Receiver inbound (after ARC seal) Chuang & Gondwana Expires 14 February 2024 [Page 18] Internet-Draft Replay Resistant ARC August 2023 ARC-Seal: i=2; d=receiver.example.org... ARC-Message-Signature: i=2; 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... ARC-Message-Signature: i=1; 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=mailinglist.example.com; dara=receiver.example.org From: user@mailinglist.example.com To: list@mailinglist.example.com The global Chain verification result is _pass_ and the message is considered DARA _authenticated_. The constructed path is [mailinglist.example.com, receiver.example.com]. 4.4.3. Originator ⇒ Naive-Forwarder ⇒Aware-Forwarder ⇒Aware-Receiver This demonstrates a naive forwarder naive.example.com that does not support DARA/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; dara=pass; chain=neutral ARC-Seal: i=2; d=intermediate.example.com; dara=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 DARA _unauthenticated_. The constructed path is [originator.example.com, naive.example.com, intermediary.example.com, receiver.example.com]. 4.4.4. Originator ⇒ Receiver ; Spammer ⇒ Victim Receiver Headers as seen by the receiver ADMD. Chuang & Gondwana Expires 14 February 2024 [Page 19] Internet-Draft Replay Resistant ARC August 2023 ARC-Seal: i=2; d=receiver.example.com ARC-Authentication-Results: i=2; dara=pass; chain=pass ARC-Seal: i=1; d=originator.example.com; dara=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; dara=pass; chain=pass ARC-Seal: i=1; d=originator.example.com; dara=receiver.example.com ARC-Authentication-Results: i=1 To: user@receiver.example.com Note at ARC set #2, it does not set a "dara=" tag, causing a path discontinuity. Due to the path discontinuity, the global Chain verification result is _fail_ and the message is considered DARA _unauthenticated_. The constructed path is [dara-fail]. 5. DMARC These protocols can act as authenticators for DMARC [RFC7489]. As noted in the Section 4, 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 DARA and verification result has a global pass, this indicates a DMARC email authentication pass. DARA and its global verification result can provide a more forwarding and body modification resilient authentication than SPF or DKIM. 6. Privacy Considerations The DARA techniques depend upon declaring all recipients into the mail headers, and signing them. This could leak Bcc and mailing list recipients to each other who don't have an expectation of seeing other hidden recipients. To prevent sharing of hidden recipients with each other, the message must be processed for each Bcc and mailing-list recipient where each recipient is uniquely declared and signed. Chuang & Gondwana Expires 14 February 2024 [Page 20] Internet-Draft Replay Resistant ARC August 2023 7. Security Considerations Care must be taken in selecting the ARC-Seal "d=" sealing domain specified with "dara=" as described in Section 3.1.2. This protocol permits sharing a sealing domain across many different MX domain identities. However forwarders doing this should be aware that receivers' reputation systems may be tied to that shared sealing identity. Forwarders SHOULD match their sealing domain to their MX domain identity when possible. 8. IANA Considerations This document has no IANA actions yet. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [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, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . Chuang & Gondwana Expires 14 February 2024 [Page 21] Internet-Draft Replay Resistant ARC August 2023 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, . [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, . 9.2. Informative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, . Appendix A. Acknowledgments Thanks goes to Emanuel Schorsch, 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. Appendix B. Parked Material This contains parked material that used to be present in the main part of the draft. In particular the ideas around Sender Receiver Co-Signing (SeRCi) and Relay Flow Identifier were moved here now that work is centered around Declare All Recipients and Affirm (DARA). B.1. Introduction 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. They find a 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 Chuang & Gondwana Expires 14 February 2024 [Page 22] Internet-Draft Replay Resistant ARC August 2023 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. B.2. Sender Receiver Co-Signing (SeRCi) B.2.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. Chuang & Gondwana Expires 14 February 2024 [Page 23] Internet-Draft Replay Resistant ARC August 2023 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 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. B.2.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 \ 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(
\ ))) 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 Chuang & Gondwana Expires 14 February 2024 [Page 24] Internet-Draft Replay Resistant ARC August 2023 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 MAIL FROM:` RCPT TO: DATA SERCI-SIGNATURE \ base64() base64(
) \ base64(signsender(sha256(
\ ))) B.2.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=" in the DNS policy record. Once discovered this domain is put in the sender's ARC-Seal as" serci=", which indicates support by the receiver for the SeRCi as well as identify the intended receiver domain. If no such 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 Chuang & Gondwana Expires 14 February 2024 [Page 25] Internet-Draft Replay Resistant ARC August 2023 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 B.2.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= () smtp.sd= smtp.s= smtp.bh=base64() smtp.hh=base64(
) smtp.t= smtp.s= smtp.b=base64() B.2.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 * "serci=": Value of the receiver's ARC-Seal "d=" domain when the receiver is SeRCi capable found from the SeRCi DNS policy record. Chuang & Gondwana Expires 14 February 2024 [Page 26] Internet-Draft Replay Resistant ARC August 2023 * "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 B.2.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 B.3. 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]. 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 Chuang & Gondwana Expires 14 February 2024 [Page 27] Internet-Draft Replay Resistant ARC August 2023 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. B.3.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 B.3.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" 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 Chuang & Gondwana Expires 14 February 2024 [Page 28] Internet-Draft Replay Resistant ARC August 2023 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 B.3.3. 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; dara=pass; chain=pass ARC-Seal: i=1; d=relay.forwarder.com; dara=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 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. B.3.4. Spammer ⇒ Gullible Forwarder ⇒ Receiver In this example the spammer does not participate in ARC or DARA/Chain protocol. The spammer forwards a message through an permissive cloud provider gullible.forwarder.com to reach the inbox of some user at destination.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; dara=pass; chain=pass ARC-Seal: i=1; d=gullible.example.com; dara=receiver.example.com ARC-Authentication-Results: i=1; spf=neutral To: user@guillible.example.com From: spoofed_user@victim.example.com Chuang & Gondwana Expires 14 February 2024 [Page 29] Internet-Draft Replay Resistant ARC August 2023 While SPF and consequently DMARC is _pass_ at the receiver, DARA/ 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 DARA/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 DARA aware, it would indicate that the replayed ARC headers would not pass ARC verification. B.3.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; dara=pass; chain=neutral ARC-Seal: i=2; d=intermediary.example.com; dara=destination.example.com ARC-Authentication-Results: i=2; chain=pass ARC-Seal: i=1; d=originator.example.com; dara=intermediary.example.com ARC-Authentication-Results: i=1 To: user@receiver.example.com While the global Chain verifi cation result is _pass_ and the message is considered DARA _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}. Chuang & Gondwana Expires 14 February 2024 [Page 30] Internet-Draft Replay Resistant ARC August 2023 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}. Authors' Addresses Weihaw Chuang Google, Inc. Email: weihaw@google.com Bron Gondwana Fastmail Pty Ltd Email: brong@fastmailteam.com Chuang & Gondwana Expires 14 February 2024 [Page 31]