Replay Resistant Authenticated Receiver Chain
draft-chuang-replay-resistant-arc-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Wei Chuang , Allen Robinson | ||
| Last updated | 2022-10-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chuang-replay-resistant-arc-00
Independent Stream W. Chuang
Internet-Draft A. Robin
Intended status: Experimental Google, Inc.
Expires: 6 April 2023 3 October 2022
Replay Resistant Authenticated Receiver Chain
draft-chuang-replay-resistant-arc-00
Abstract
DKIM (RFC6376 (https://tools.ietf.org/html/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 (https://www.rfc-editor.org/rfc/rfc8617.html)). 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.
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 6 April 2023.
Chuang & Robin Expires 6 April 2023 [Page 1]
Internet-Draft Replay Resistant ARC October 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
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. ARC Set Improvements . . . . . . . . . . . . . . . . . . . . 4
4. Declare All Recipients and Affirm (DARA) . . . . . . . . . . 4
4.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Header Examples . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. MBP-Mailing-List-MBP . . . . . . . . . . . . . . . . 7
4.3.2. MBP-MBP-Replay-MBP . . . . . . . . . . . . . . . . . 8
4.3.3. MBP-Naive-Forwarder-MBP . . . . . . . . . . . . . . . 9
5. Sender Receiver Co-Signing (SeRCi) . . . . . . . . . . . . . 9
5.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . 13
5.2. Header Example . . . . . . . . . . . . . . . . . . . . . 13
6. Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Header Examples . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. MBP-Mailing-List-MBP . . . . . . . . . . . . . . . . 15
6.2.2. MBP-Naive-Forwarder-Aware-Forwarder-MBP . . . . . . . 15
6.2.3. MBP-MBP-Replay-MBP . . . . . . . . . . . . . . . . . 16
7. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Chuang & Robin Expires 6 April 2023 [Page 2]
Internet-Draft Replay Resistant ARC October 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.
These 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.
2. Terminology and Definitions
Acronyms
* ARC (RFC8617 (https://www.rfc-editor.org/rfc/rfc8617.html)) - is a
protocol that is meant to resolve some of the issues for DMARC
(RFC7489 (https://datatracker.ietf.org/doc/html/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
(RFC8601 (https://www.rfc-editor.org/rfc/rfc8601)) by
Administrative Management Domain (ADMD) and a versioning mechanism
for them.
* Authentication-Results (RFC8601 (https://www.rfc-editor.org/rfc/
rfc8601))- A header containing a list of validation results and
comments.
* DKIM (RFC6376 (https://tools.ietf.org/html/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 (https://tools.ietf.org/html/rfc6376)
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.
* DMARC (RFC7489 (https://datatracker.ietf.org/doc/html/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.
Chuang & Robin Expires 6 April 2023 [Page 3]
Internet-Draft Replay Resistant ARC October 2022
* 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.
3. ARC Set Improvements
This protocol uses ARC (RFC8617 (https://www.rfc-editor.org/rfc/
rfc8617.html)) to describe all ADMDs using the ARC set number as the
ADMD version numbers. The initial ARC set "i=1" is defined for the
message originator, and signs for the outbound message with an empty
ARC-Authentication-Results. Traditionally ARC signing happens on
inbound, however with these changes ARC implementations should be
modified to sign on outbound as well that enables marking origination
and forwarding. This protocol adds additional new ARC-Seal tag/
values to describe protocol settings and new ARC-Authentication-
Results status and comments. This protocol also heavily leverages
ARC sealing and message signing which in turn leverages DKIM
cryptographic primitives.
4. Declare All Recipients and Affirm (DARA)
4.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
Chuang & Robin Expires 6 April 2023 [Page 4]
Internet-Draft Replay Resistant ARC October 2022
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 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.
Chuang & Robin Expires 6 April 2023 [Page 5]
Internet-Draft Replay Resistant ARC October 2022
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 shouldn't 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 passes. 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 & Robin Expires 6 April 2023 [Page 6]
Internet-Draft Replay Resistant ARC October 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/fail/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.
4.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".
4.3. Header Examples
4.3.1. MBP-Mailing-List-MBP
First MBP outbound (after ARC seal)
Chuang & Robin Expires 6 April 2023 [Page 7]
Internet-Draft Replay Resistant ARC October 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
4.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 & Robin Expires 6 April 2023 [Page 8]
Internet-Draft Replay Resistant ARC October 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
4.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
5. Sender Receiver Co-Signing (SeRCi)
Chuang & Robin Expires 6 April 2023 [Page 9]
Internet-Draft Replay Resistant ARC October 2022
5.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
(https://datatracker.ietf.org/doc/html/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 <sender domain> <selector> <signature>
Chuang & Robin Expires 6 April 2023 [Page 10]
Internet-Draft Replay Resistant ARC October 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 <timestamp>
MAIL FROM:<sender>
RCPT TO:<recipient>
DATA <message>
SERCI-SIGNATURE <sender domain> <selector> <base64(signsender(<base64(message hash),destination domain,timestamp>)))>
Chuang & Robin Expires 6 April 2023 [Page 11]
Internet-Draft Replay Resistant ARC October 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 (https://www.rfc-
editor.org/rfc/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 RFC822 FROM 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), in addition to return OK , the receiver adds the
signature as part of the SeRCi ARC-Authentication-Results as a
comment:
ARC-Authentication-Results i=1; serci=<pass|fail>
(<sender domain>,<selector>,<base64(message hash)>,
<timestamp>,<signature>);
The destination domain present in the signature is the same as that
ADMD's ARC-Seal "d=" domain. The domain, selector, message-hash,
timestamp and the signature should allow a 3rd party to verify the
signature given a public key. Verification success or failure would
also be indicated in the ARC-Authentication-Results for SeRCi as
"serci=<pass|fail\>". The receiver indicates agreement i.e.
verification success with the sender's signed signature by sealing
the signature and indicating a passing result. A 3rd party can take
the ARC-seal and SeRCi signatures and verify them to prove that a
message was sent from the sender to receiver at the given time.
If a sender does not provide a SERCI-SIGNATURE, most likely this is
because the sender is unaware of the protocol. However a receiver
MAY lookup the sender's SeRCi policy contained in the DNS txt record.
If it detects such an active policy yet SERCI-SIGNATURE was not
Chuang & Robin Expires 6 April 2023 [Page 12]
Internet-Draft Replay Resistant ARC October 2022
issued, then the receiver may note a SeRCi ARC-Authentication-Results
verification failure. Lack of SERCI-SIGNATURE potentially may happen
due to MiTM in the SMTP transaction even with TLS.
5.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.
ARC-Authentication-Results tags
* "serci=": Value of "pass" if sender/recipient signing validation
succeeds, otherwise "fail".
5.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
6. Chaining
A receiver may check that a message was forwarded from the originator
to it without discontinuities, and as intended by the originator.
With SeRCi the sender defines a tag "serci=" with a value of the
intended destination domain. If a discontinuity is detected, that
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. Moreover the
path that the message traverses can be used as the message flow
identifier in a reputation system. It can help differentiate benign
message flows from malicious ones to help identify a different form
of replay. If the originator is malicious and intends for a message
to be replayed even as part of an identified ADMD path, a path based
Chuang & Robin Expires 6 April 2023 [Page 13]
Internet-Draft Replay Resistant ARC October 2022
reputation system can better segregate those malicious messages than
a domain based one.
We define nodes of the path as the ARC-Seal "d=" identities and form
edges from SeRCi destination domain identities. Because building the
edges of a path is recursive, we call this chain building. The edge
is defined as a pair of nodes n1, n2 where n1 is some ARC-Seal "d="
domain and the "SeRCi=" domain is n2. This assumes that validation
results from SeRCi and potentially DARA have already run and the
results already populate the ARC-Authentication-Results. Chain
building starts at the origination at ARC set "i=1", and walk through
the ARC headers to the final receiver's ARC set "i=N". First the
verifier looks up the SeRCi policy associated with the ARC set "i=1"
ARC-Seal "d=" domain. If there is a valid SeRCi policy, then chain
building can proceed. At ARC set "i=1" only the ARC seal and
message-signature is checked. Starting at ARC set "i=2", path
verifier MUST evaluate the local result, meaning the ARC seal,
message-signature and SeRCi verification results, and the prior ARC
set results are correct, and take the AND of the results. If any one
of them is a failure or neutral, the path result is a failure or
neutral. If the SeRCi result is missing, the path verifier checks if
there was "snr=" tag at that node or prior node, then treats the
SeRCi result as neutral, to tolerate the naive receiver. If not then
treat the SeRCi result as missing and hence a fail. Otherwise if all
the local results passed, then the current path results is a pass.
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/)) The path verifier SHOULD incorporate meaning AND the DARA
local results if available as well. In the local evaluation, the
verifier SHOULD independently verify the SeRCi signature instead of
taking the result from ARC-Authentication-Result and having to trust
an externally generated result. The path verifier then evaluates the
next ARC set results until it reaches the final recipient to compute
a global result. That global result is published in the final
receiver's at ARC set "i=N" ARC-Authentication-Results as a "chain="
result. The chain builder will internally collect the list of ARC-
Seal "d=" nodes from ARC set 1 to N for when there is a "serci=" edge
defined and passing result. The "snr=" domain may also be used to
fill in a naive domain in the path. The path is for reputation
building but this is not added to ARC-Authentication-Results.
6.1. Definitions
ARC-Authentication-Results tags
Chuang & Robin Expires 6 April 2023 [Page 14]
Internet-Draft Replay Resistant ARC October 2022
* "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.2. Header Examples
6.2.1. MBP-Mailing-List-MBP
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=terminator.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=terminator.example.com
ARC-Authentication-Results: i=3; serci=pass; chain=pass
ARC-Seal: i=2; d=mailinglist.example.com; serci=terminator.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 path verification result is "pass". The constructed path is
(originator.example.com, mailinglist.example.com,
terminator.example.com).
6.2.2. MBP-Naive-Forwarder-Aware-Forwarder-MBP
This example includes naive forwarder naive.example.com that doesn't
not support SeRCi. This is taken after the last MBP.
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
Chuang & Robin Expires 6 April 2023 [Page 15]
Internet-Draft Replay Resistant ARC October 2022
The path verification result is "neutral". The constructed path is
(source.example.com, naive.example.com, intermediary.example.com,
destination.example.com).
6.2.3. MBP-MBP-Replay-MBP
Final headers as seen by the victim MBP 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 path verification result is
"fail". The constructed path is (source.example.com,
destination.example.com).
7. DMARC
These protocols can act as authenticators for DMARC (RFC7489
(https://datatracker.ietf.org/doc/html/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. This
protocol modifies DMARC to permit the SeRCi and Chain to authenticate
for DMARC. It requires alignment with the RFC822 domain for SeRCi
sender's ARC-Seal "d=" domains. With Chain, that is further
restricted to the originating sender's domain at ARC set "i=1".
8. Privacy Considerations
9. Security Considerations
10. IANA Considerations
This document has no IANA actions yet.
Appendix A. Acknowledgments
Thanks goes to Brandon Long, John R. Levine, Murray S. Kucherawy
and Bruce Nan for their sage advice.
Authors' Addresses
Chuang & Robin Expires 6 April 2023 [Page 16]
Internet-Draft Replay Resistant ARC October 2022
Weihaw Chuang
Google, Inc.
Email: weihaw@google.com
Allen Robin
Google, Inc.
Email: arobins@google.com
Chuang & Robin Expires 6 April 2023 [Page 17]