Independent Stream W. Chuang Internet-Draft Google, Inc. Intended status: Experimental B. Gondwana Expires: 24 June 2023 Fastmail Pty Ltd A. Robin Google, Inc. 21 December 2022 Replay Resistant Authenticated Receiver Chain draft-chuang-replay-resistant-arc-03 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 (https://www.rfc- editor.org/rfc/rfc6376.html#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. 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 24 June 2023. Chuang, et al. Expires 24 June 2023 [Page 1] Internet-Draft Replay Resistant ARC December 2022 Copyright Notice Copyright (c) 2022 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 . . . . . . . . . . . . . . . 3 2. ARC Set Improvements . . . . . . . . . . . . . . . . . . . . 4 3. Declare All Recipients and Affirm (DARA) . . . . . . . . . . 5 3.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Header Examples . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. MBP ==> Mailing-List ==> MBP . . . . . . . . . . . . 7 3.3.2. MBP ==> MBP-Replay ==> MBP . . . . . . . . . . . . . 8 3.3.3. MBP ==> Naive-Forwarder ==> MBP . . . . . . . . . . . 9 4. Sender Receiver Co-Signing (SeRCi) . . . . . . . . . . . . . 9 4.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . 12 4.2. Header Example . . . . . . . . . . . . . . . . . . . . . 13 5. Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Chain Building Algorithm . . . . . . . . . . . . . . . . 13 5.2. Path Interpretation . . . . . . . . . . . . . . . . . . . 15 5.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 15 6. Chaining Header Examples . . . . . . . . . . . . . . . . . . 15 6.1. MBP ==> Mailing-List ==> MBP . . . . . . . . . . . . . . 16 6.2. MBP ==> Naive-Forwarder ==>Aware-Forwarder ==>MBP . . . . 16 6.3. MBP ==> Spammer ; Replay ==> MBP . . . . . . . . . . . . 17 6.4. Spammer ==> Gullible Forwarder ==> MBP . . . . . . . . . 17 7. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Chuang, et al. Expires 24 June 2023 [Page 2] Internet-Draft Replay Resistant ARC December 2022 1. Introduction This protocol provides two different techniques to authenticate email by domain that is replay resistant. 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. 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 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. This also depends upon ARC improvements to ensure that the results of the first two techniques are propagated correctly to the receiver. 1.1. Terminology and Definitions Acronyms * Authenticated Received Chain (ARC) [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, and is based on DKIM, but suffers from similar issues as DKIM replay. ARC defines digital signatures and Authentication-Results by ADMD and a versioning mechanism for them. * Authentication-Results [RFC8601]- A header containing a list of validation results and comments. * DomainKeys Identified Mail (DKIM) [RFC6376]- IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit. - DKIM replay- [RFC6376] 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. * Sender Policy Framework (SPF) [RFC7208]- IETF standard for authenticating sending servers typically based on IP address. * ADministrative Management Domain (ADMD) [RFC5598] defines Mail Submission Agent (MSA), Mail Transfer Agent (MTA) and Mail Delivery Agent (MDA). Chuang, et al. Expires 24 June 2023 [Page 3] Internet-Draft Replay Resistant ARC December 2022 * Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]- Defines a sender's domain identity and from that a sender's message handling policy when messages are being spoofed. It defines using SPF and DKIM as methods to determine the authenticity of messages. * Signed RFC822 header recipients- These identities are defined by _To_, _Cc_ and _Forwarded-to_ headers, and MUST be a signed headers present in the ARC-Seal. * SMTP recipients- The RFC5321 MAIL FROM recipients are disclosed during the SMTP transmission. These identities define the inboxes that the message is intended for. 2. ARC Set Improvements This protocol leverages the concepts and features of ARC [RFC8617] for propagating authentication results and protecting the integrity of the headers and message body. It adds additional new ARC-Seal tag/values to describe protocol settings and new ARC-Authentication- Results status and comments as described in later sections. As the ARC chain identifies the message traversal over the forwarding path, this uses ARC set number as the per ADMD versioning. Unlike ARC, this proposal mandates that the aware ADMDs explicitly identify themselves as an ARC set in the identified path or makes explicit when the message exits the identified path into some naive, unaware ADMD as described later. The identified path traverses ADMDs starting with the MSA, optionally traverses one or more MTA, and terminates delivery into the inbox at the MDA. The MSA ADMD i.e. the responsible originating sender of the message is identified as the initial ARC set "i=1". This protocol requires that the _From_ header domain MUST be the same as the ARC- Seal d= domain i.e. tying the sender's identity to the cryptographic signer that claims that. As the originator has no email authentication results, the ARC-Authentication-Results MUST be empty. Similarly when the message is delivered to the inbox by the MDA ADMD at ARC set "i=N", it alters the ARC set to make termination identifiable and to make it more difficult to replay the ARC sets. The MDA strips the ARC-Seal and ARC-Message-Signature but leaves behind the ARC-Authentication-Result before sending the message to the MUA. A message lacking ARC-Seal and ARC-Message-Signatures has been delivered to the inbox, and the last ARC set ARC-Authentication- Result present indicates the MDA ARC set. ADMDs that act as MTA will upon receiving a message, forward to some new destination. Note that an ADMD MAY be both a MTA and MDA i.e MAY forward the message and deliver to some inbox. Chuang, et al. Expires 24 June 2023 [Page 4] Internet-Draft Replay Resistant ARC December 2022 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 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 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 or ARC-Seal, or from missing headers, that is "hard" _fail_. Prior failures from "i=N-1" to "i=1" ARC-Seal are treated as _softfail_. 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 We can harden the protocol 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. 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. Forwarded-to: i=1; user@example.com The _Forwarded-to_ header MUST be signed by the ARC-Message-Signature i.e. be present in the "h=", then prepended to the headers of the message. For privacy, if there are multiple recipients, the message MUST be split and signed exclusively for each _Forwarded-to_ Chuang, et al. Expires 24 June 2023 [Page 5] Internet-Draft Replay Resistant ARC December 2022 recipient to maintain privacy between recipients. Subsequent forwarders MUST not strip the _Forwarded-to_ header from the message. To handle the email forwarder and mailing list scenario, we also use the _Forwarded-to_ header to indicate that a message is sent to a new recipient. Messages sent to a new ADMD but with the same recipient identity disclosed by _Forwarded-to_ MAY reuse the prior header. Senders and receivers MAY variously support the Declare All Recipients and Affirm (DARA) protocol or not, so the protocol needs to be tolerant of naive ADMDs. 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. In this protocol, that sender publishes their capability in the ARC-Seal as "dara=" tag/value, and whether the receiver SHOULD validate recipients. A value of "v" indicates that 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. A value of "d" indicates that the receiver MAY choose to discretionally validate the recipients. If a receiver validates the recipients, it SHOULD treat recipient verification failure as _neutral_ and SHOULD treat success as _pass_. The discretionary validation mode is to support the scenario of sending to a naive ADMD that does not support ARC or the DARA protocol. Because such naive forwarders MAY not add any indication of its presence e.g. adding an ARC set, the sender MUST protect subsequent DARA aware receivers from misinterpreting prior settings while allowing for recipient updates that MAY otherwise trigger false positive verification failures. All ADMD supporting the DARA protocol MUST publish a DNS txt policy record as described below. The sender fetches the receiver's policy record to determine whether to select the required verification "dara=v" which is done when the receiver supports the DARA protocol, otherwise the sender selects the optional "dara=d" validation profile. In addition when the receiver does not support the protocol, the sender always identifies the individual signed recipient. This MAY be needed when the recipient is in the _To_, or _Cc_ headers, and in this case also adds a _Forwarded-to_ header per recipient, then signs the message only for that recipient. Unique identification of the recipient and the receiving domain allows a receiver to adjust the reputation system in case there is a replay attack. 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. Chuang, et al. Expires 24 June 2023 [Page 6] Internet-Draft Replay Resistant ARC December 2022 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 ARC-Message-Signature and if so, put them into a set of signed headers. 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 policy depending on the sender's capabilities as described in the ARC-Seal "dara=" tag/value. The result of this check SHOULD be published in the ARC-Authentication- Results as dara=_pass_ or _fail_ or _neutral_. The DARA DNS policy record identifies whether an ADMD supports the protocol. It is a TXT DNS record located at the same domain name as the MX record. Quite likely it will share the policy record with SPF. Such a policy record starts with a SeRCi version number "dara_version=" which MUST be set to "ver1.0" indicating that ADMD supports DARA. While usually the sender looks up the DARA TXT DNS record, a 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.2. Definitions DNS TXT Policy tags * "dara_version=": Value of "ver1.0" if the ADMD supports the DARA verification protocol. ARC-Seal tags * "dara=": Value of "v" if the sender mandates that the receiver verify the recipients. Value "d" if the sender asks the receiver to optionally verify the recipients, and writes a _pass_ if the recipient verification passes. ARC-Authentication-Results tags * "dara=": Value of _pass_ if recipient validation passes, otherwise _fail_. In some circumstances this tag/value MAY not be set or be treated as _neutral_. 3.3. Header Examples 3.3.1. MBP ==> Mailing-List ==> MBP First MBP outbound (after ARC seal) Chuang, et al. Expires 24 June 2023 [Page 7] Internet-Draft Replay Resistant ARC December 2022 ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: mailing.list@example.com Mailing-List inbound (after ARC seal) ARC-Seal: i=2; dara=v ARC-Authentication-Results: i=2; dara=pass (rcpt.to mailing.list@example.com matches signed header) ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: mailing.list@example.com Mailing-List outbound (after ARC seal) Forwarded-to: i=2; user@example.com ARC-Seal: i=2; dara=v ARC-Authentication-Results: i=2; dara=pass (rcpt.to mailing.list@example.com matches signed header) ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: mailing.list@example.com Final MBP inbound (after ARC seal) ARC-Seal: i=3; dara=v; ARC-Authentication-Results: i=3; dara=pass (rcpt.to user@example.com matches signed header) Forwarded-to: i=2; user@example.com ARC-Seal: i=2; dara=v; ARC-Authentication-Results: i=2; dara=pass (rcpt.to mailing.list@example.com matches signed header) ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: mailing.list@example.com 3.3.2. MBP ==> MBP-Replay ==> MBP First MBP outbound (after ARC seal) ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: user@example.com Second MBP inbound (after ARC seal) ARC-Seal: i=2; dara=v; ARC-Authentication-Results: i=2; dara=pass (rcpt.to user@example.com matches signed header) ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: user@example.com Chuang, et al. Expires 24 June 2023 [Page 8] Internet-Draft Replay Resistant ARC December 2022 Above message captured by spammer, modified (add additional headers) and then resent. A spammer might send the message to john.doe@example.com which would be unspecified in the headers. Victim (last) MBP inbound (after ARC seal) ARC-Seal: i=3; dara=v ARC-Authentication-Results: i=3; dara=fail (rcpt.to john.doe@example.com mismatches signed header); ARC-Seal: i=2; dara=v ARC-Authentication-Results: i=2; dara=pass (rcpt.to user@example.com matches signed header); ARC-Seal: i=1; dara=v ARC-Authentication-Results: i=1 To: user@example.com 3.3.3. MBP ==> Naive-Forwarder ==> MBP This describes a forwarder that doesn't not support DARA. First MBP outbound (after ARC seal) Forwarded-to: i=1; user@naive.example.com ARC-Seal: i=1; dara=d ARC-Authentication-Results: i=1 To: user@example.com Forwarder headers will be the same as above as the forwarder is naive to the protocol. Final MBP inbound (after ARC seal). In this case the envelope recipient will change weihaw@example.com. The declared recipient user@other.example.com will mismatch the envelope recipient, and fail DARA. However the protocol is set to optional verification with DARA=d, and so does not report the failure. ARC-Seal: i=2; dara=v ARC-Authentication-Results: i=2 Forwarded-to: i=1; user@naive.example.com ARC-Seal: i=1; dara=d ARC-Authentication-Results: i=1 To: user@naive.example.com 4. Sender Receiver Co-Signing (SeRCi) Chuang, et al. Expires 24 June 2023 [Page 9] Internet-Draft Replay Resistant ARC December 2022 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 GoT 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. 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 base64 message hash used in the outbound ARC-Message-Signature, destination domain as defined in the next paragraph, and timestamp. That signature then SHOULD be base64 encoded and disclosed to the receiver as: SERCI-SIGNATURE Chuang, et al. Expires 24 June 2023 [Page 10] Internet-Draft Replay Resistant ARC December 2022 where domain corresponds to the sender's DKIM domain and selector that is used to find the DKIM public key DNS record. 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 )))> Chuang, et al. Expires 24 June 2023 [Page 11] Internet-Draft Replay Resistant ARC December 2022 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 "SERCI_version=" which MUST be set to "ver1.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 ([RFC8601]) 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 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 "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 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 a tag "serci=" tag and _pass_ or _fail_ result. It also adds the signature as part of the SeRCi ARC- Authentication-Results as a comment. This is illustrated as: ARC-Authentication-Results i=1; serci= (,,, ,); 4.1.1. Definitions DNS TXT Policy tags * "serci_version=": Value of "ver1.0" if the ADMD supports the SeRCi verification protocol. * "serci=": Value of the receiver's ARC-Seal "d=" domain ARC-Seal tags * "serci=": Value of the receiver's ARC-Seal "d=" domain when the receiver is SeRCi capable. * "snr=": Value of RFC822 recipient's domain name when the receiver is naive of SeRCi. Chuang, et al. Expires 24 June 2023 [Page 12] Internet-Draft Replay Resistant ARC December 2022 ARC-Authentication-Results tags * "serci=": Value of "pass" if sender/recipient signing validation succeeds, otherwise "fail". 4.2. Header Example ARC-Seal: i=2; d=destination.example.com ARC-Authentication-Results: i=2; serci=pass (source.example.com, message_hash_base64, selector, 1664511950175, signature_base64) ARC-Seal: i=1; d=source.example.com; serci=destination.example.com ARC-Authentication-Results: i=1 To: user@destination.example.com 5. Chaining The local results of 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 SeRCi declaration of "snr=" vs "serci=" which clarifies definitively which of these two 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. 5.1. Chain Building Algorithm The following defines an algorithm for path building using 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 building. It starts at the destination at ARC set "i=N", and walks through the ARC headers to Chuang, et al. Expires 24 June 2023 [Page 13] Internet-Draft Replay Resistant ARC December 2022 the originator ARC set "i=1". The edge is defined as a pair of nodes (_d_N_ , _d_(N-1)_) where the sender's ARC-Seal "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 "serci=" result is missing, the verifier checks if there is instead a "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_. 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 and potentially 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 SeRCi verification result, and optionally the DARA verification result, and take the AND of those results. If all of them are _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/)) As with ARC improvements, this protocol recommends continuing Chain verification even if the sender's Chain result is failure or neutral, to provide forensics evidence for subsequent receivers. Receivers SHOULD independently verify the SeRCi signature rather than taking the result from ARC-Authentication-Result and having to trust an externally generated result. At the originator ARC set "i=1" corresponding to _d_1_, the verifier first verifies alignment between header _From_ domain and the ARC-Seal "serci=" domain. That domain defines _d_1_, and the verifier looks up the SeRCi policy associated with the domain which MUST exist. If they are not aligned, then the message is not considered originated at "i=1", and local Chain verification is considered _neutral_ as likely the message was forwarded to some SeRCi aware domain. In addition the ARC seal validation for "i=1" 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. Chuang, et al. Expires 24 June 2023 [Page 14] Internet-Draft Replay Resistant ARC December 2022 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, 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=" 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_. 5.2. Path Interpretation 5.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_. 6. Chaining Header Examples The following two examples illustrate working SeRCi/Chain-Building verification. This is followed by an example of DKIM replay attack. The last example is illustrative of how this protocol behaves with a SPF upgrade attack. Chuang, et al. Expires 24 June 2023 [Page 15] Internet-Draft Replay Resistant ARC December 2022 6.1. MBP ==> Mailing-List ==> MBP 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. First MBP outbound (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 Final MBP inbound (after ARC seal) ARC-Seal: i=3; d=destination.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 The global Chain verification result is _pass_ and the message is considered SeRCi _authenticated_. The constructed path is [originator.example.com, mailinglist.example.com, destination.example.com]. 6.2. MBP ==> Naive-Forwarder ==>Aware-Forwarder ==>MBP This demonstrates a naive forwarder naive.example.com that doesn't not support SeRCi. The headers represent what would be seen after inbound delivery to the destination MBP. Chuang, et al. Expires 24 June 2023 [Page 16] Internet-Draft Replay Resistant ARC December 2022 ARC-Seal: i=3; d=destination.example.com ARC-Authentication-Results: i=3; serci=pass; chain=neutral ARC-Seal: i=2; d=intermediate.example.com; serci=destination.example.com ARC-Authentication-Results: i=2; chain=neutral ARC-Seal: i=1; d=source.example.com; snr=naive.example.com ARC-Authentication-Results: i=1 To: user@destination.example.com The global Chain verification result is _neutral_ and the message is considered SeRCi _unauthenticated_. The constructed path is [source.example.com, naive.example.com, intermediary.example.com, destination.example.com]. 6.3. MBP ==> Spammer ; Replay ==> MBP 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=destination.example.com ARC-Authentication-Results: i=2; serci=pass; chain=pass ARC-Seal: i=1; d=source.example.com; serci=destination.example.com ARC-Authentication-Results: i=1 To: user@destination.example.com 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]. 6.4. Spammer ==> Gullible Forwarder ==> MBP In this example the spammer does not participate in ARC or this 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=destination.example.com ARC-Authentication-Results: i=2; spf=pass; serci=pass; chain=pass ARC-Seal: i=1; d=gullible.forwarder.com; serci=destination.example.com ARC-Authentication-Results: i=1; spf=neutral To: user@destination.example.com From: spoofed_user@victim.example.com Chuang, et al. Expires 24 June 2023 [Page 17] Internet-Draft Replay Resistant ARC December 2022 While SPF and consequently DMARC is _pass_ at the destination, 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.forwarder.com, destination.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, destination.example.com] or [victim.example.com, gullible.forwarder.com, destination.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.forwarder.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. 7. DMARC These protocols can act as authenticators for DMARC [RFC7489]. In particular SeRCi can act similarly to SPF in authenticating peers, while Chain's path is similar to DKIM in being tolerant of forwarding but unlike DKIM can detect replay. This protocol modifies DMARC to permit the SeRCi/Chain building results to authenticate for DMARC as a third authenticator after SPF and DKIM. As noted before, this protocol requires alignment with the _From_ header domain and SeRCi originator's ARC-Seal "d=" domains at ARC set "i=1". Assuming From alignment, a SeRCi/Chain building global pass on a message will indicate 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. 8. Privacy Considerations 9. Security Considerations 10. IANA Considerations This document has no IANA actions yet. 11. Normative References Chuang, et al. Expires 24 June 2023 [Page 18] Internet-Draft Replay Resistant ARC December 2022 [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, . [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, . Appendix A. Acknowledgments Thanks goes to Brandon Long, John R. Levine, Murray S. Kucherawy, Emanuel Schorsch and Bruce Nan for their knowledgeable feedback. Authors' Addresses Weihaw Chuang Google, Inc. Email: weihaw@google.com Bron Gondwana Fastmail Pty Ltd Email: brong@fastmailteam.com Allen Robin Google, Inc. Chuang, et al. Expires 24 June 2023 [Page 19] Internet-Draft Replay Resistant ARC December 2022 Email: arobins@google.com Chuang, et al. Expires 24 June 2023 [Page 20]