Review of: Authenticated Received Chain (ARC) Protocol
I-D: draft-ietf-dmarc-arc-protocol-14
orgination
Review by: D. Crocker
Review date:
(The usual caveat about my reviews: Comments are a mixture of major and
minor, substantive and trivial, objective and stylistic. Do with them
as you wish. /d)
Summary:
The draft starts using terms of art that haven't been defined yet.
Also it should do quite a bit more of cross-citing, when using a term,
so the read knows where to go to find out the underlying technical
detail that the term covers.
The beginning of a spec should have summary text that explains
a) explains the problem or needs space; what issue is being
addressed by the spec?
b) what goals are being sought; how can the reader know whether
the spec has done its job?
c) the basic approach/design of the spec; and optionally how this
differs from existing, related work.
This allows a superficial reading by technical and non-technical folk,
where the latter don't proceed to the rest of the document, but they
walk away with a useful and accurate sense of what this spec is about.
Given the current draft's existing organization, all 3 of these should
be in Section 1.
The draft does not really explain why certain mechanisms or choices are
present. For example, every time there is a reference to DKIM
similarities, there should be text explaining why DKIM wasn't just used.
Also, an ARC set has two signatures, rather than one. Why?
General comments on readability:
* Make sure discussions are partitioned well, and that topics aren't
conflated.
* Try for shorter sentences and make sure all sequences are
extremely clear and logical -- having validation come before
signing/sealing is an issue here.
* When using a term, make sure it has been defined earlier. When the
term is defined externally, make sure the citation to it is precise, ie,
fine-grained into the external document. (the draft does a pretty good
job of this.)
* Make sure specialized terms have narrow application -- 'fail' vs.
'validate' is an example of a possible problem here, since they are
formal terms.
The design of DKIM extensively considere signature survivability in
transit. It's limitations in that regard are well-known. There should
be some commentary about ARC on this issue. I think the substance is
merely that ARC signature survivability is approximately the same as
DKIM's when relaxed mode is usedm but this should be documented
explicitly. In particular, any differences in survivability expected
from differences in the choice of header fields that are covered should
be discussed carefully. ("carefully" doesn't necessarily require
verbosity...)
Organizational issue:
I'm finding myself thinking that the ARC text should be split into
separate documents, but I'm not sure what to suggest. Some of the text
is essentially specifying an extension to DKIM. Some of it is extending
Authentication Results. Some of it is extending DMARC.
When a spec is really covering a number of separate (but related)
topics, I usually find that things get /much/ simpler if they are
documented separately. First, the text usually is simpler. Second, the
lifecycle of the components can proceed independently.
DMARC is what's motivating this work but, really, it isn't DMARC work
(in the technical sense; I'm not raising an issue about it's being in
that working group.) I often note the distinction between what
motivates some work, versus the nature of the work. For example, email
authentication would be a good idea even if there were no abuse; but the
abuse is an effective motivator.
Another attempt to summarize the nature of ARC:
ARC is a response to message handling authentication fragility
(which encompsses both SPF and DKIM.) It deals with some types of
fragility by providing mid-transit message analysis and signing. The
analysis is to perform authentication prior to expected breakage, and
then to package the analysis results for consideration by later
receivers, including the final destination.
Reporting is an adjunct function. As with DMARC, it might turn out to
be especially useful, but it's not a primary goal.
Yet DMARC is heavily referenced in the draft. I'd like to find a way to
take it completely out of the critical path of the main document. Taking
it out of everything but the Introduction would be ideal.
This permits focusing on ARC as a basic enhancement of authentication,
rather than as integral with DMARC.
Detailed:
Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the
way to its destination, and create an attached, authenticated record
of the status at each step along the handling path, for use by the
final recipient in making choices about the disposition of the
message. Changes in the message that might break existing
authentication mechanisms can be identified through the ARC Set of
header fields.
Given that 'authentication' is in the title, redundant use of that core
semantic word in the explanatory text "authentication of the email
message" in summary statements like the Abstract is actually not very
helpful. What does it mean to 'conduct' authentication of a message? It
could mean many things. Which one is actually meant? We should not
assume the reader has a background in this general area, nevermind this
specific area.
(Yes, this is 'just' the abstract, but that's the bit of text that gets
circulated, to recruit more readers. So its readability should target a
wide audiencew.)
Hmmm. 'conduct' authentication sounds like verification rather than
signing. The value add of ARC is that a series of handlers affix
authentication information.
I suggest adding this existing, excellent sentence from the Intro:
ARC provides an authenticated "chain of custody" for a message,
allowing each entity that handles the message to see what entities
handled it before, and to see what the authentication status of the
message was at each step in the handling.
(I added 'authenticated'.)
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Concepts . . . . . . . . . . . . . . . . . . . . 5
1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5
1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6
1.3.1. Terms defined and used in this document . . . . . . . 6
1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7
2. Protocol Elements and Features . . . . . . . . . . . . . . . 7
2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8
2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9
2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9
2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9
2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9
2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10
2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10
2.7. Optional Participation . . . . . . . . . . . . . . . . . 10
2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10
2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11
2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11
3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13
3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Authentication-Results Information . . . . . . . . . . . 15
4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
4.3. Responding to ARC Validity Violations During the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . . . 16
5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
Andersen, et al. Expires October 25, 2018 [Page 2]
Internet-Draft ARC-Protocol April 2018
5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
6. Recording and Reporting the Results of ARC Evaluation . . . . 17
6.1. Information from an ARC Evaluation . . . . . . . . . . . 17
6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17
6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Authentication-Results Method Registry Update . . . . . . 19
8.2. Email Authentication Result Names Registry Update . . . . 19
8.3. Definitions of the ARC header fields . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
10. Evaluating the Efficacy of the ARC Protocol (Experimental
Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Success Consideration . . . . . . . . . . . . . . . . . 21
10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22
10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22
10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22
10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22
10.3.3. Distinguishing Valuable from Worthless Trace
Information . . . . . . . . . . . . . . . . . . . . 22
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11.1. GMail test reflector and incoming validation . . . . . . 24
11.2. AOL test reflector and internal tagging . . . . . . . . 24
11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25
11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25
11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25
11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26
11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27
11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27
11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27
11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31
B.1.1. Here's the message as it exits the Origin: . . . . . 31
B.1.2. Message is then received at example.org . . . . . . . 32
B.1.3. Example 1: Message received by Recipient . . . . . . 34
Andersen, et al. Expires October 25, 2018 [Page 3]
Internet-Draft ARC-Protocol April 2018
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35
B.2.1. Here's the message as it exits the Origin: . . . . . 35
B.2.2. Message is then received at example.org . . . . . . . 36
B.2.3. Example 2: Message received by Recipient . . . . . . 40
B.3. Example 3: Mailing list to forwarded mailbox with source 42
B.3.1. Here's the message as it exits the Origin: . . . . . 42
B.3.2. Message is then received at example.org . . . . . . . 43
B.3.3. Example 3: Message received by Recipient . . . . . . 48
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction
This initial part of this section should lay out the nature of the
problem being solved and the nature of the benefit being sought. I think
it does a reasonable job of this.
Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] have become common. However, their end-to-end utility is
limited by the effects of intermediaries along the transmission path,
which either are not listed (for SPF) or which break digital
signatures (for DKIM). These issues are described in substantial
detail in those protocols' defining documents as well as in [RFC6377]
and [RFC7960].
Technologies that build upon the use of SPF and DKIM can reduce the
success of fraudulent email campaigns. To this end, Domain-based
Mail Authentication, Reporting and Conformance (DMARC) [RFC7489],
validates the domain of the RFC5322.From header field. However its
use along email transmission paths that have independent
intermediaries, such as some forwarders and essentially all mailing
list services, produces false positive rejections that are
problematic, both for the message authors, the intermediary
service(s), and for those they are interacting with.
[RFC7960] documented the need for a mechanism which would survive
legitimate alteration of a message, in spite of breaking the
associated SPF and DKIM information so that the end receiver
breaking the associated SPF and DKIM information
->
associated SPF and DKIM information that is broken
(subtle distinction. The first ARC signer presumably did the breaking,
but later signers presumably didn't...)
system(s) can avoid those false positive rejections on delivery.
Authenticated Received Chain (ARC) builds upon DKIM mechanisms to
provide a sequence of signatures that provide a view of the handling
sequence for a message, especially the points where alterations of
the content might have occurred. Equipped with this more complete
Authenticated Received Chain (ARC) adapts DKIM so that signatures
are affixed to the message, as a recorded audit of the message
handling sequence, especially...
information, the recipient system(s) can make a more informed
handling choice, reducing or eliminating the rejections that would
handling -> disposition
(handling includes relaying, and that's not what is meant here.)
occur with the use of DKIM and/or SPF alone.
Andersen, et al. Expires October 25, 2018 [Page 4]
Internet-Draft ARC-Protocol April 2018
1.1. General Concepts
My hope, for a sub-section like this, is that it supplies enough detail
to be useful for a non-technical reader to understand the basic approach
ARC is taking to solve the problem layed out in the initial part of the
Introduction.
ARC provides a "chain of custody" for a message, allowing each entity
that handles the message to see what entities handled it before, and
to see what the authentication status of the message was at each step
in the handling. The handling entity can then put its own entry into
the chain of custody and then relay the message to the next handler.
This section is missing quite a bit of conceptual explanation for ARC's
purpose and design. I suggest adding something like this here:
The ARC chain of custody provides information to augment receiver
analysis, when the authentication information provided by the
originator fails. ARC supplies related analysis information
that is obtained during transit.
ARC adds intermediate analysis report information to the message,
along with two signatures. The first signs the message, itself, in
a manner that is similar to DKIM. The second signs the chain of
signatures, by ARC-participating intermediaries, thereby creating
an authenticated chain of custody.
When the message reaches final delivery, the decision to accept and
deliver the message, or, alternatively, to reject, discard, or
quarantine it, can take the chain of custody into account, applying
local policy in addition to policies advertised by the (purported)
sending domain. Consider, for example, this scenario:
applying -> evaluating whether to apply
(btw, why plural 'policies'? DMARC asserts a single policy.)
1. A sender from mysender.example posts a message to a mailing list
hosted at listmania.example;
2. The mailing list modifies the message by prepending the list name
to the subject line, then sends it to the subscribers;
3. One of the subscribers is [email protected], which
receives the message from listmania.example.
Assuming the original message was DKIM-signed and mysender.example
published an SPF record, the handling by the mailing list will break
the DKIM signature because of the message modification, and the
forwarding will cause the SPF check to fail in the next step. But
listmania.example can add ARC headers to the message to add itself to
the document's chain of custody. When mail.service.example sees the
message, it can see that SPF and DKIM validation fail, but it can
also see that both of these succeeded when they were checked by
listmania.example, and can verify listmania's assertion.
but it can see that listmania.example reports that it succeeded
when that site received the message.
(the reason for suggesting the wording change is to move from implying
that it actually succeeded to the more tentative -- but accurate -- fact
that listmania's claim of success requires trusting listmania... IMO
this essential distinction cannot be stressed enough, about ARC.)
As part of its evaluation of the message for delivery,
mail.service.example can see that mysender.example publishes a DMARC
policy asking that unauthenticated messages be rejected. But is can
also see the assertion by listmania.example that the message was
correctly authenticated when the message arrived there, and if it
accepts that assertion, it can accept the message for further
processing, rather than reject it, based on the additional
information that ARC has provided.
This is pedantic, but I suggest having a paragraph break for the last
part, to so that this essential point is harder to miss. Hence:
If mail.service.example accepts the assertion by the intermediary,
listmania.example, then it can accept the message...
1.2. Differences Between ARC and DKIM
There should probably be some text here that explain why these
differences are needed. That is, answer the question: Why not just use
DKIM?
(BTW, the early discussions consider differences that would make the
signature somewhat more survivable during transit, but there's no
reference to that here. I don't know whether that goal survived...)
In DKIM, every participating signing agent attaches a signature that
is based on some of the content of the message, local policy, and the
domain name of the signing agent's Administrative Management Domain
(ADMD). Any verifier can process such a signature; a verified
delete 'participating'
'local policy' doesn't have any obvious meaning to me.
The domain name doesn't have to be tied to the ADMD. It usually is, but
it doesn't have to be. For example, an authorized third party such as a
bulk sending service might sign on behalf of a client; this practice is
common. So perhaps:
, and a domain name.
Just drop the additional detail.
Andersen, et al. Expires October 25, 2018 [Page 5]
Internet-Draft ARC-Protocol April 2018
signature means that the domain referenced in the signature's "d="
parameter has some responsibility for handling the message. An
artifact of using digital signature technology for this means that
verification also ensures that the portion of the message that was
"covered" by the signature has not been altered since the signature
was applied. The signatures themselves are generally independent of
one another.
In contrast, a validated ARC Set conveys the following pieces of
information:
ARC Set hasn't been defined, so the reader won't know what it means. For
this introductory section, before technical definitions and details have
been offered, I suggest keeping the discussion more generic or at least
self-explanatory.
Perhaps:
In contrast, ARC supplies a set of signatures; their validation
conveys...
1. An assertion that, at the time that the intermediary ADMD
processed the message, the various assertions (such as SPF, DKIM-
Signature(s) and/or ARC Chain) already attached to the message by
other ADMDs were or were not valid;
"the intermediary ADMD"? There can be a sequence of them. I think you
mean something like "the first ARC intermediary ADMD" or somesuch.
2. As with DKIM, an assertion that, for a validated ARC signature,
the domain name in the signature takes some responsibility for
handling of the message and that the covered content of the
message is unchanged since that signature was applied;
3. A further assertion that binds the ARC evaluation results into
the ARC Chain sequence.
This is a well-formed and relatively simple sentence, but I'm finding
myself having no idea what it actually means. Really. I suggest
re-forming the sentence to establish what the purpose/benefit of this
point is.
"ARC evaluation results"? What does this mean. It hasn't been
introduced yet.
1.3. Definitions and Terminology
This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 ([RFC2119][RFC8174]).
Because many of the core concepts and definitions are found in
[RFC5598], readers should to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email.
Many of the core concepts and definitions used here are found in
Internet Mail Architecture [RFC5598]. So readers are encouraged to
be familiar with it, an in particular...
(Found myself thinking it better to include the doc title and not just
the citation.)
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
1.3.1. Terms defined and used in this document
Style suggestion:
Use hanging indents, rather than bullets, with the term unquoted and as
the label. So, for example:
ARC-Authentication-Results (AAR): an ARC header field described
in Section 3.2.
Also, I think that the definitions section should contain actual
definitions, not just pointers to other sections. The danger, of
course, is the possibility of creating multiple definitions for the same
term. The way to avoid that is to make sure that the later discussion
of the term, supplying the technical detail, doesn't contain a 'definition'.
That is, define here, elaborate there.
o "ARC-Authentication-Results" (AAR) - an ARC header field described
in Section 3.2.
o "ARC-Message-Signature" (AMS) - an ARC header field described in
Section 3.3.
Andersen, et al. Expires October 25, 2018 [Page 6]
Internet-Draft ARC-Protocol April 2018
o "ARC-Seal" (AS) - an ARC header field described in Section 3.4.
o "ARC Set" - A single group of the header fields introduced in
Section 2.1 is called an "ARC Set".
I think the 'single group' is a group created by a single ARC
participating site, yet? Making this clear, here, would be helpful.
o "ARC Chain" - the complete sequence of ARC Sets for a message.
The ARC Chain represents a "chain of custody" for the message,
recording its authentication status at each ARC-participating ADMD
that handled the message.
1.3.2. Referenced Definitions
Might want to move the above text that suggests familiarity with 5598 to
be here, since you've got direct citations to it here.
The following terms are defined in other RFCs. Those definitions can
be found as follows:
o ADMD - [RFC5598], Section 2.3
o MTA - [RFC5598], Section 4.3.2
o MSA - [RFC5598], Section 4.3.1
o MDA - [RFC5598], Section 4.3.3
The three header fields that are part of this specification borrow
heavily from existing specifications. Rather than repeating all of
the formal definitions that are being reused in ARC, this document
only describes and specifies changes in syntax and semantics.
Presumably the above paragraph is refined by the following one, but
there's nothing in the writing the makes that explicit. I suggest
swapping the paragraphs, and adapting the above (with text to make it
refer explicitly to the next one.)
Language, syntax, and other details are imported from DKIM [RFC6376].
Specific references can be found below.
2. Protocol Elements and Features
Hmmm. As I've read through this section, I'm finding myself thinking
there needs to be a distinction between core concepts, like key
management and chain of custody, versus details of practice, such as all
failures are permanent. And this distinction should split into two
sections.
As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the contents of the email
message it has sealed. However, for a valid and passing ARC Chain, a
Final Receiver is able to ascertain:
"valid and passing"? what does this mean? eg, what would valid and not
passing mean?
"Final Receiver" is capitalized, but hasn't been defined. I assume this
is a modification of the RFC 5598 Receiver term. Might want to cite
Receiver in terminology, above, and not capitalize final. (Note that
because ARC covers re-posted messages that go through intermediaries
such as mailing list, there really can be multiple 'receivers', in RFC
5598 terminology; so the 'final' qualifier makes sense, but it needs to
be explained.)
'seal' is a term of art -- and an important one for ARC -- but it hasn't
been defined.
o all (participating) domains that claim responsibility for handling
(and possibly modifying) the email message in transit;
o trace information, including:
* the [RFC7601] Authentication-Results each participating ADMD
saw; and
* additional data needed to compile a DMARC report for the
sending domain.
Hmmm. This formally ties ARC to DMARC and it doesn't specify what the
detail is. Since ARC really is only tied to DKIM, I suggest altering
the wording to this.
Andersen, et al. Expires October 25, 2018 [Page 7]
Internet-Draft ARC-Protocol April 2018
Given this information, each receiver is able to make a more informed
local policy decision regarding message processing and, ultimately,
delivery to the end user in spite of authentication failure(s) and to
inform the message orgination system(s) through the DMARC report(s).
orgination -> origination
I assume there is nothing in ARC that alters the nature or detail in a
DMARC report? Hence the 'inform' comment here seems to imply
ARC-related detail in DMARC reports that won't be supplied...
Every participant in an ARC Chain, except for the originating sender
originating sender -> Originator
Another rfc 5598 term.
and Final Receiver, is both an ARC Validator (when receiving) and
then an ARC Sealer (when sending a message onward).
This uses detail (validator and sealer) that hasn't been defined yet.
Perhaps fudge the issue:
and final Receiver, does both validation of existing ARC headers
and signing of new ARC information (when sending a message onward.)
_INFORMATIONAL_: It is important to understand that validating and
then immediately sealing a message leaves no room for message
modification, and many early implementations of ARC did not initially
work because both operations were performed in a single pass over the
message.
The following protocol features are functional parts and design
decisions related the protocol that are not specific to either
Validators or Sealers, but ensure that the ARC Chain conveys this
information to a Final Receiver.
The following features are common to participants doing either (or
both) of validating or signing. These ensure that the ARC Chain...
2.1. The "ARC Set" of Header Fields
Each "ARC Set" consists of the following three new header fields:
delete 'new'.
Explain where each set comes from. ie, who generates a set?
1. ARC-Authentication-Results (referred to below as "AAR"):
virtually identical in syntax to an Authentication-Results field
[RFC7601], this field records the results of all message
authentication checks done by the recording ADMD at the time the
message arrived. Additional information is placed in this field
compared to a standard Authentication-Results field in order to
support a more complete DMARC report;
What is the specific info that is additional? Put in a pointer to the
AAR specification.
2. ARC-Message-Signature (referred to below as "AMS"): virtually
identical in syntax to DKIM-Signature, this field contains the
signature about the message header and body as they existed at
the time of handling by the ADMD adding it (including any
modifications made by the sealing ADMD); and
header -> header fields
about -> over
handling -> signing
of the handling by the ADMD... sealing ADMD)
->
of the signing. The ADMD does the signing after making modifications
to the signing.
How is this different from a DKIM signature?
3. ARC-Seal (referred to below as "AS"): highly similar in structure
and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of
these fields added by prior ADMDs.
An ARC participant always adds all of these header fields before
relaying a message to the next handling agent _en route_ to its
destination. Moreover, they each have an "instance number" that
increases with each ARC Set in the handling chain so that thei
thei -> the
Andersen, et al. Expires October 25, 2018 [Page 8]
Internet-Draft ARC-Protocol April 2018
original order can be preserved and the three related header fields
can be processed as a set.
2.1.1. Instance Tags
ARC includes an indicator in its header fields to show the order in
which the header fields comprising an ARC Chain were added, and the
specific members of each ARC Set. This is known as the "instance",
and the indicator is an "i=" tag/value. That is, the members of the
first ARC Set affixed to a message will all include "i=1". This is
described in detail in section Section 3.1.
2.2. Chain Validation Status
ARC includes a mechanism which denotes the state of the ARC Chain at
each step. The "chain validation status" ("cv" tag/value) is used to
communicate the current chain status within the ARC Chain and also
through Authentication-Results and ARC-Authentication-Results stamps
as well as DMARC reporting.
This language seems to mean that chain status is communicated in 3 ways
(cv, auth-results, and arc-auth-results.) I suspect that that is not
the intended meaning, but I don't even have a guess about what is
actually meant. Really.
Also, 'mechanism' might not be the most helpful word. I suspect
'indicator' is closer.
The chain validation status has one of three possible values:
o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) or mediator from a Message Submission Agent
(MSA) or when any upstream handlers may not be participating in
ARC handling;
o fail: The message has a chain whose validation failed;
o pass: The message has a chain whose validation succeeded.
I suggest adding a pointer to the definition of chain validation (3.4.2)
here, and a citing the computation of validation as per Section 4.
2.3. Trace Information
ARC includes trace information encoded in the AAR. While section
trace of what? explain its nature, enough to distinguish it from a
variety of reasonable other meanings. In particular, of course, how is
it different from Received?
Section 3.2 defines what information must be provided, sealing ADMDs
may provide additional information, and validating receivers may use
this trace information as they find it useful.
The text here isn't specifying detail, so don't use normative language.
must be -> is
may provide -> can provide
delete the ", and..." clause. It's using normative language but
provides no substance.
2.4. Key Management
The public keys for ARC header fields follow the same requirements,
syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. ARC places no requirements on the
selectors and/or domains used for the ARC header field signatures.
Andersen, et al. Expires October 25, 2018 [Page 9]
Internet-Draft ARC-Protocol April 2018
2.5. All Failures are Permanent
Because ARC Chains are transmitted across multiple intermediaries,
all errors, even temporary ones, become unrecoverable and are
considered permanent.
Any error validating or sealing a chain, for whatever reason, MUST
result in a "cv=fail" verdict as documented in Section 3.4.2.
2.6. Chain of Custody
At a high level, an ARC Chain represents a chain of custody of
authentication and other trace information (AAR) related to a
message, signed by each handler of the message. Each link in the
chain (AMS) is designed to be brittle, insofar as it survives only
until the next modification of the message. However, the sequence of
intermediaries in the handling chain (AS) is designed to remain
intact over the entirety of the chain.
I suspect "chain of custody of authentication" is not a correct summary
of what ARC does; I'm not even sure what it means. The language needs
to distinguish purpose from method. Authentication is a method, not a
purpose. I'd guess the summary description should be something like:
An ARC Chain establishes a validated handling sequence for message,
through participating email handlers of it.
Whatever the final text of such a summary winds up being, it should
appear much sooner -- presumably in the Introduction or at least in the
definitions -- and it shouldn't be repeated deeper in the document.
An AMS is a 'link in the chain'??? I susect not really, though I can
see why it might be called that. I suspect each seal constitutes a link.
The ARC Chain can be conceptualized through an analogy with the chain
of custody for legal evidence. The material evidence itself is
sealed within an tamper-proof bag (AMS) each time. When handed to a
new party, that party both vouches for the state of the received
evidence container (AAR) and signs for the evidence on a chain of
custody report form (AS). As with all analogies, this one should not
be taken to interpretive extremes, but primarily used as a conceptual
framework.
can be conceptualized through an analogy with the
->
is similar to a
(I had a 10th grade English teacher who beat my convoluted language to
death, until I learned to simplify it and make it more direct. For the
most part.)
material evidence -> material evidence (the message)
each time -> by each participating handler
The comparison to legal c-o-e gets tortured and isn't explained
adequately. For example, it uses 'evidence container' as if the term is
established, but it hasn't been and is used only once. And the AAR isn't
the container. It's a report of the assessment of the contents in the
container.
An ARC Chain that is valid and passing has the attributes listed
above in Section 2.
'passing'???
something like failures are permanent is not an 'attribute'. this adds
to my suggestion to distinguish core concepts (possibly worth calling
attributes) from practices.
2.7. Optional Participation
Validating an existing chain and then adding your own ARC Set to a
message allows you to claim responsibility for handling the message
and modifications, if any, done by your ADMD to benefit message
delivery downstream. However, no ADMD is obligated to perform these
actions.
claim responsibility -> claim some responsibility
'handling modifications'? (the parallel construction doesn't quite work.)
done by your ADMD to benefit message delivery downstream
->
done by you.
(Not sure that use of you/your here works. At the least, the document
should be reviewed carefully for the perspective of such usage, to
decide whether it is consistent and accurate. I'm not objecting to the
form -- though some with nitpick the informality in a spec -- but rather
expressing concern that it not be inconsistent.)
However -> NOTE:
(The however declares a contrast with the preceding text, but there
isn't any contrast.)
2.8. Broad Responsibility to Seal
Any mediator ([RFC5598], section 5) that modifies a message may seal
its own changes. ARC is not solely intended for perimeter MTAs.
introduce mediator in the terminology section.
'may'? or SHOULD?
There's nothing here that asserts or describes 'responsibility'.
Also, the language here seems to proscribe sealing for handlers that
don't modify the message. Is that intended?
Andersen, et al. Expires October 25, 2018 [Page 10]
Internet-Draft ARC-Protocol April 2018
2.9. One Chain to Rule Them All
A message can have only one ARC Chain on it at a time (see
can -> MUST
Section 3.1). Once broken, the chain cannot be continued, as the
cannot -> MUST NOT (?)
chain of custody is no longer valid and responsibility for the
message has been lost. For further discussion of this topic and the
designed restriction which prevents chain continuation or re-
establishment, see [ARC-USAGE].
2.10. Sealing is Always Safe
Offhand, I suspect the title is not correct. Each Seal is another
opportunity for failure.
Even when an ARC Chain is valid and passes, its value is limited to
very specific cases. An ARC Chain is specifically designed to
provide additional information to a receiver evaluating message
delivery in the context of an authentication failure and otherwise be
benign. Specifically:
o properly adding an ARC Set to a message does not damage or
invalidate an existing chain,
o sealing a chain when you did not modify a message does not
negatively affect the chain, and
unless the seal later fails to validate...
o validating a message exposes no new threat vectors (see
Section 9).
_INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
and/or modifying a message, it may elect to seal all inbound mail.
For complex or nested ADMD relationships such as found in some hosted
mail solutions, this "inbound seal" can be used to facilitate
traversal of internal boundaries as well as properly conveying
incoming state to any egress MTAs that may need to assert a seal upon
exit from the ADMD. Since these internal relationships are highly
implementation dependent, this protocol definition can not usefully
explore such usage except to note that it is intentionally allowed
within the scope of this specification.
3. The ARC Header Fields
3.1. Instance ('i=') Tag
3.1. The Common Instance ('i=') Tag
(I found it disconcerting to have the section say header fields and have
the first sub-section not be a header field. The suggested title change
might avoid that reaction.)
The header fields comprising a single ARC Set are identified by a
common "instance" tag value. The instance tag is a string in each
header field value that complies with the "tag-spec" ABNF found in
Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the
text representation of a positive integer, indicating the position in
the ARC sequence this set occupies, where the first ARC Set is
numbered 1. In ABNF terms:
The second sentence is generic about all tags used in the spec, not just
i=. So it should be moved elsewhere, if it isn't already redundant.
Andersen, et al. Expires October 25, 2018 [Page 11]
Internet-Draft ARC-Protocol April 2018
position = 1*2DIGIT ; 1 - 50
instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
Why an upper limit of 50?
Valid ARC Sets MUST have exactly one instance of each header field
(of three) for a given instance value and signing algorithm.
(_INFORMATIONAL:_ Initial development of ARC is only being done with
a single allowed signing algorithm, but parallel work in the DCRUP
working group [1] is expanding that. For handling multiple signing
algorithms, see [ARC-MULTI].)
Algorithm agility is a long-established requirement for use in security
components. The approach typically defines a registry for algorithms,
while specifyin the requirement that all implementations support a default.
The 'i' tag value can range from 1-50 (inclusive).
ARC Chains longer than the defined maximum count MUST be marked as
failed.
_INFORMATIONAL_: Because the AMS and AS header field values are made
header field values -> header fields
made up of -> use unordered
up of tag-spec constructs, the i= tag may be found anywhere within
the header field value, but is represented throughout this spec in
the header field value -> the contents of the header field
the initial position for convenience. Implementers are encouraged to
place the i= tag at the beginning of the field value to facilitate
human inspection of the headers.
Implementers -> However implementers
3.2. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results header field is syntactically and
semantically identical, except for the header field name itself and
its instance tag, to an Authentication-Results header field (defined
in Section 2.2 of [I-D-7601bis]).
Except for the header field name itself and the presence of an
instance tag, the ARC-Authentication-Results header field is
syntactically and semantically identical to an Authentication-
Results header field (defined in Section 2.2 of [I-D-7601bis]).
Formally, the header field is specified as follows using ABNF
[RFC5234]:
arc-info = instance [CFWS] ";" authres-payload
arc-info = instance [CFWS] ";" authres-payload ; per I-D-7601bis
(Note that instance /is/ order dependent in this ABNF...)
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
The AAR MUST contain all Authentication-Results from within the
participating ADMD, regardless of how many Authentication-Results
headers are on the message.
participating ADMD -> participating ADMD creating this AAR
3.3. ARC-Message-Signature (AMS)
The ARC-Message-Signature header field is simplified version of a
DKIM-Signature header field [RFC6376], with the following
modifications:
o There is an "i" tag, as described in Section 3.1.
Adding a tag is not a 'simplification'...
Andersen, et al. Expires October 25, 2018 [Page 12]
Internet-Draft ARC-Protocol April 2018
o There is no "v" tag defined for the AMS header. As required for
undefined tags (in [RFC6376]), if seen, it MUST be ignored.
ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC-
Authentication-Results) MUST NOT be included in the content covered
by the signature in the signature in this header field.
"by the signature in the signature"???
Anyhow this proscription seems an odd use of MUST NOT, to me. There
should be a formal specification of what MUST, SHOULD, and/or MAY be
included. Anything not listed there is excluded.
The AMS SHOULD include any DKIM-Signature header fields already
present on the message in the header fields covered by this
signature.
"present on the message in the header fields covered by this signature"???
Authentication-Results header fields MUST NOT be included since they
are likely to be deleted by downstream ADMDs (per Section 5 of
[RFC7601]), thereby breaking the AMS signature.
3.4. ARC-Seal (AS)
The ARC-Seal header field is syntactically and semantically similar
to a DKIM-Signature field, with the following exceptions:
Delete: ", with the following exceptions"
Saying "similar" is enough.
o Tag "i" tag is described in Section 3.1.
o Tags "a", "b", "d, "s", "t" from Section 3.5 of
[RFC6376].
o Tag, "cv" is defined in Section 3.4.2
o The ARC-Seal covers none of the body content of the message. It
only covers specific header fields as defined below:
Section 3.4.1. No body canonicalization is done.
o Only "relaxed" header canonicalization (Section 3.4.2 of
[RFC6376]) is used.
o The only supported tags are "i" (from Section 3.1 of this
document), and "a", "b", "d, "s", "t" from Section 3.5 of
[RFC6376].
o An additional tag, "cv" is defined in Section 3.4.2
See above for suggested cleanup/streamlining of tag specifications
3.4.1. Covered Header Fields
The ARC-Seal signs a specific canonicalized form of the ARC Set
"specific canonicalized form"??? what does this mean, given that
'relaxed' is dictated above.
header values. The ARC set header values are compiled in increasing
compiled in -> arranged into
(this being a computer science discipline, and 'compiled' being a term
of art, let's avoid possible confusion...)
instance order, starting at 1, and include the set being added at the
time of sealing the message.
Within a set, the header fields are listed in the following order:
1. ARC-Authentication-Results
2. ARC-Message-Signature
Andersen, et al. Expires October 25, 2018 [Page 13]
Internet-Draft ARC-Protocol April 2018
3. ARC-Seal
Where the ARC-Seal is the one being generated, it is input to the
hash function in its final form except with an empty "b=" value, in
the same manner by which a DKIM-Signature signs itself ([RFC6376],
section 3.7).
Note that the signing scope for the ARC-Seal is modified in the
situation where a chain has failed validation (see Section 5.1).
I don't quite understand what this means.
3.4.2. The 'cv' Tag
A new tag "cv" (chain validation) indicates the outcome of evaluating
the existing ARC Chain upon arrival at the ADMD that is adding this
header field. The values are defined per Section Section 2.2.
Section Section -> Section
add:
and are based on the Verifier Actions of Section 4.
In ABNF terms:
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status
Nevermind the values. What is the basis for asserting a value? Where
is that defined?
4. Verifier Actions
I continue to find it odd that the section on Verifier Actions precedes
Signer Actions. I continue to suggest swapping them, to reflect the
actual handling sequence for a message.
A verifier takes the following steps to validate the ARC Chain.
Canonicalization, hash functions, and signature validation methods
are imported from Section 5 of [RFC6376].
1. Collect all ARC Sets currently on the message. If there were
none, the ARC state is "none" and the algorithm stops here.
were -> are
2. Check the morphology of the ARC Chain. If any of these
conditions are not met, the chain state is "fail" and the
algorithm stops here:
1. Each ARC Set must be complete (e.g., contains exactly one of
each of the three ARC-specific header fields);
e.g. -> i.e.
(if there are more conditions than the one stated here, how is the
algorithm to know what to check for?)
2. The instance values must form a continuous sequence from 1..N
with no gaps or repeats;
continuous -> contiguous
1..N -> from 1 to the highest instance value found (N)
(N wasn't defined.)
3. The cv value for all ARC-Seal(s) must be non-failing:
1. For i > 1, the value must be "pass";
2. For i = 1, the value must be "none".
3. For each ARC-Message-Signature from the "N"th instance to the
first, validate the AMS:
3. From set N..1, validate each ARC-Message-Signature:
Andersen, et al. Expires October 25, 2018 [Page 14]
Internet-Draft ARC-Protocol April 2018
1. If the "N"th instance (most recent) signature fails, then the
chain state is "fail" and the algorithm stops here.
*** I think there needs to be some careful discipline to distinguish
validation failure from resulting status (eg, chain) failure. I suggest
the discipline to be using different language rigorously. I propose
'does not validate' for the former and 'fails' for the latter.
2. If one of the prior AMS signatures fails to validate (for
instance "M"), then set the oldest-pass value to the lowest
AMS instance number which passed (M+1) and go onto the next
step (there is no need to check any other (older) AMS
signatures). This does not affect the validity of the chain.
2. If a prior AMS signature (instance M) does not validate,
then set Oldest-Pass to M+1 and go...
3. If all AMS signatures verify, set the oldest-pass value to
zero (0).
"oldest"? hmmm. It's actually the newest. That is, it is the most
recent signature, in the chain of signatures.
4. For each ARC-Seal from the "N"th instance to the first, validate
the seal.
4. From ARC-Seal N..1, validate each seal
1. If any seal is not valid, the chain state is "fail" and the
algorithm stops here.
1. If a Seal does not validate, the chain statis is fail;
terminate the algorithm here.
2. If all seals pass validation, then the chain state is "pass",
and the algorithm is complete.
2. If all seals validate...
The end result of the verifier's checks via this algorithm MUST be
added into the Authentication-Results header(s) for the ADMD.
for /which/ ADMD?
_INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does
"invalid or does not pass" seems redundant.
not pass SHOULD NOT draw negative conclusions without a good
understanding of the wider handling context. Until ARC usage is
This normative sentence has no substance. It does not specify a
specific action and it cannot be tested. It also is arguably outside
the scope of the spec...
widespread, intermediaries will continue to modify messages without
ARC seals.
They'll do that after it's widespread too.
As with a failing DKIM signature ([RFC6376] Section-6.3), a message
with a failing ARC Chain MUST be treated the same as a message with
no ARC Chain.
+1
4.1. Authentication-Results Information
Certain information pertinent to ascertaining message disposition can
be lost in transit when messages are handled by intermediaries. For
example, failing DKIM signatures are sometimes removed by MTAs, and
Since a failed DKIM signature is to be treated the same as having no
DKIM signature, its removal should not affect disposition...
most DKIM signatures on messages modified by intermediaries will
Except, for example, when adding Received:. So the statement needs some
sort of qualifier. Not elegant, but perhaps something simple like
"substantially modified". (I could argue for 'substantively' rather
than 'substantially', but that's just fussy...)
fail. Recording the following information in the Authentication-
Results stamped as part of the ARC evaluation provides a mechanism
for this information to survive transit through a particular ADMD.
Stamped ARC evaluation results is limited to the Chain Validation
status (cv) from Section 2.2.
"stamped"?
Andersen, et al. Expires October 25, 2018 [Page 15]
Internet-Draft ARC-Protocol April 2018
The ptypes and properties defined in this section SHOULD be recorded
in the Authentication-Results:
o smtp.client-ip - The connecting client IP address from which the
message is received;
o header.oldest-pass - The instance number of the oldest AMS that
still validates, or 0 if all pass.
Shouldn't the label identify which method is involved, to ensure the
reference is unambiguous?
4.2. Handling DNS Problems While Validating ARC
DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a "cv=fail" verdict.
Should there be any wiggle room allowed here, for holding the message
and retrying the DNS query, given how often DNS queries have a temporary
failure?
4.3. Responding to ARC Validity Violations During the SMTP Transaction
If a receiver determines that the ARC Chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code.
5. Sealer Actions
An ARC sealer MUST take the following actions when presented with a
message:
1. Before creating an ARC signature, perform any other, normal
authentication and/or signing, so that the ARC signature can
cover those results.
can cover those results
->
has the option of covering any resulting message additions or
modifications
2. Build and attach the new ARC Set:
1. If an ARC Chain exists on the message, then set "N" equal to
the highest instance number found on the chain (i=);
otherwise set "N" equal to zero for the following steps.
exists -> already exists
2. Generate and attach to the message an ARC-Authentication-
Results header field as defined in Section Section 3.2, using
instance number N+1 and the same content from the previous
step.
Section Section
3. Generate and attach to the message an ARC-Message-Signature
header field as defined in Section 3.3 above, using instance
number N+1.
4. Generate and attach to the message an ARC-Seal header field
using the general algorithm described in Section 3.4 above,
Andersen, et al. Expires October 25, 2018 [Page 16]
Internet-Draft ARC-Protocol April 2018
the chain validation status as determined in Section 4, and
instance number N+1.
5.1. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case
of a chain failure MUST be only the matching instance headers created
by the MTA which detected the malformed chain, as if this newest ARC
Set was the only set present.
This seems oddly worded. The fine-grained detail of saying b= seems
distracting or possibly misleading. I'm not exactly sure what's
precisely meant to be specified here, but here's a guess:
In the case of a chain failure, the header fields covered by the
newest AS signature MUST be only those specified for the newest ARC set,
of the signer that detected the malformed chain.
_INFORMATIONAL:_ In the case of a malformed or otherwise invalid
chain there is no way to generate a deterministic set of AS header
fields ({#implicit_as_h}) so this approach is mandated.
Do you mean deterministic or do you mean accurate? In either case, it
might be worth elaborating on your point a bit more.
I suspect you also mean 'set of AS header fields across the entire chain'?
6. Recording and Reporting the Results of ARC Evaluation
The evaluation of an ARC Chain provides information which will be
useful to both the receiver (or intermediary) and to the initial
sender of the message. This information should be preserved and
reported as follows.
sender -> originator
'should'? normative?
6.1. Information from an ARC Evaluation
The evaluation of an ARC Chain produces a list of domain names for
participating intermediaries which handled the message, to wit:
"for"? perhaps "of"?
o A list of the "d=" domains found in the validated ARC-Seal header
fields
o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily
validated)
In the case of a failed chain, only the terminal ARC Set is covered
by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC Set.
6.2. Recording (local) ARC Evaluation Results
Receivers who process an attached ARC Chain SHOULD add an
"arc=[pass|fail|policy]" method annotation into a locally-affixed
Authentication-Results [RFC7601] header field along with any salient
comment(s).
Details of the ARC Chain which was evaluated should be included in
the Authentication-Results and AAR headers per Section Section 4.1.
Andersen, et al. Expires October 25, 2018 [Page 17]
Internet-Draft ARC-Protocol April 2018
6.3. DMARC Reporting of ARC Findings - Interim
Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data
discovered in the ARC evaluation, which at a minimum SHOULD include:
* the Chain Validation status, * the domain and selector for each AS,
* the IP addresses of the mail originating ADMD:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13</comment>
</reason>
</policy_evaluated>
In the sample above, d2.example is the sealing domain for ARC[2] and
d1.example is the sealing domain for ARC[1].
Intermediary message handlers SHOULD generate DMARC reports on
messages which transit their system just like any other message which
they receive. This will result in multiple reports for each mediated
message as they transit the series of handlers. DMARC report
consumers should be aware of this behaviour and make the necessary
accommodations.
7. Privacy Considerations
The ARC Chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this compatible
with their operating goals.
Reporting back to the Originator also divulges Receiver details.
<< REVIEWED ENDED HERE >>
D/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
