Review of: draft-ietf-dmarc-arc-protocol-16 (partial)
Date: 17 Jul 18
Reviewed by: D. Crocker
Summary:
I gave a review for -14 and will skip the pro forma functional summary.
I reviewed the initial portions of the -16 draft and see some basic and
pervasive language problems that are serious enough to make it likely
that a reader will misunderstand core ARC concepts. I've suggested
alternative language, where I could.
d/
Detail:
Abstract
The Authenticated Received Chain (ARC) protocol allows Internet Mail
Handlers to attach assertions of message authentication state to
individual messages. As messages traverse ARC-enabled Internet Mail
Handlers, additional ARC assertions can be attached to messages to
form ordered sets of ARC assertions that represent authentication
state along each step of message handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions
to inform message disposition decisions, to identify Internet Mail
Handlers that might break existing authentication mechanisms, and to
convey original authentication state across trust boundaries.
My review of -14 noted problems with the abstract. While there have
been some changes, the Abstract remains too... abstract. While the
current text is better it really does not provide simple, direct
statements about the problem(s) ARC is addressing nor the solution or
benefit that it enables.
Text like this needs to be written for people who are not trained in
theoretical computer science and are not already deeply enmeshed in this
work.
For convenience, here's what I wrote in the -14 review, for a suggested
change:
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'.)
Note also that while typical discussion of ARC refers to it as
establishing a chain of custody, no language like that is in the
Abstract. I think that's a serious omission.
Consider the 'general concepts' section, below and the sub-topics. Note
that nothing like 'assertions of message authentication state' shows up
there.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 6
3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7
3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 7
4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 10
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13
5.1.3. Only One Authenticated Received Chain Per Message . . 13
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14
5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14
5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14
Andersen, et al. Expires January 18, 2019 [Page 2]
Internet-Draft ARC-Protocol July 2018
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16
5.2.2. Responding to ARC Validation Failures During the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 16
5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16
6. Communication of Validation Results . . . . . . . . . . . . . 17
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Communicate Authentication Results Across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17
7.1.1. Message Scanning Services . . . . . . . . . . . . . . 17
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18
7.2. Inform Message Disposition Decisions . . . . . . . . . . 18
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 20
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 21
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Email Authentication Results Names Registry Update . . . 22
10.2. Email Authentication Methods Registry Update . . . . . . 22
10.3. Definitions of the ARC header fields . . . . . . . . . . 23
11. Experimental Considerations . . . . . . . . . . . . . . . . . 23
11.1. Success Consideration . . . . . . . . . . . . . . . . . 24
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
11.3.3. What Trace Information is Valuable . . . . . . . . . 25
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
12.1. GMail test reflector and incoming validation . . . . . . 26
12.2. AOL test reflector and internal tagging . . . . . . . . 26
12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27
12.6. Copernica/MailerQ web-based validation . . . . . . . . . 28
12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
12.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 30
12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 31
Andersen, et al. Expires January 18, 2019 [Page 3]
Internet-Draft ARC-Protocol July 2018
13.2. Informative References . . . . . . . . . . . . . . . . . 32
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 33
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction
The utility of widely deployed email authentication technologies such
as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
by intermediate handlers. This impact is thoroughly documented in
the defining documents for SPF and DKIM and further discussed in
[RFC6377] and [RFC7960].
The utility of technologies that build upon SPF and DKIM (such as
DMARC [RFC7489]) is similarly impacted by intermediate handlers. The
disruption of authentication mechanisms for legitimate messages by
intermediate handlers can impact all aspects of Internet Mail -
message authors, message recipients, and even the intermediary
handler itself.
editorial, to simplify and reduce redundancies, replace the above paragraph:
DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So
their failures that are caused by the actions of intermediate handlers
can in turn cause legitimate mail to be incorrectly rejected or misdirected.
(drop the 'all aspects' sentence.)
Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication processing results
to a message's ordered set of processing results. ARC encapsulates
processing results in a DKIM signature derivative to grant other
handlers the ability to verify the authenticity of the individual
processing results as well as the aggregate set and sequence of
results.
Ordered sets of processing results can be used by ARC-enabled
Internet Mail Handlers to inform message handling disposition, to
identify where alteration of message content might have occurred, and
to provide additional trace information for use in understanding
message handling paths.
2. General Concepts
ARC is loosely based on concepts from evidence collection. Evidence
is usually collected, labeled, stored, and transported in specific
ways to preserve the state of evidence and to document all processing
steps.
I think this means based on 'legal' concepts of evidence, really. While
it theoretically should apply to all handling of anything one might call
evidence, this really is drawing from the legal world, isn't it?
Andersen, et al. Expires January 18, 2019 [Page 4]
Internet-Draft ARC-Protocol July 2018
2.1. Evidence
A term like "authentication state" needs to be defined or at least
explained, given its importance to the text here.
There's an argument one can make that the term is actually
inappropriate. I don't think this activity has a concept of an
authentication state machine. One might invent such a thing and might
even be useful, but it hasn't been done, has it?
While it's not as verbally tight, I suspect language more like
"validation of message authentication information" or "authentication
assessment" or "authentication validity" are both more intuitive and
correct.
(BTW, this might be why 'evidence' is a problematic term, since, really,
assertions about prior validations constitute a kind of hear-say; it's
second-hand information, not direct, objective 'evidence'. Though it
might be a bit facile, an alternative choice could be 'testimony'...)
In ARC's situation, the "evidence" is a message's authentication
state at any point along the delivery path between origination and
final delivery. Authentication state can change when intermediate
handlers modify message content (headers and/or body content), route
messages through unforeseen paths, or change envelope information.
The authentication state of a message is determined upon receipt of a
message and documented in the Authentication-Results header field(s).
ARC extends this mechanism to survive transit through intermediary
ADMDs.
2.2. Custody
"Custody" refers to when an ARC-enabled Internet Mail Handler
processes a message. When a handler takes custody of a message, the
handler becomes a Custodian and attaches their own evidence
(authentication state upon receipt) to the message. Evidence is
added in such a way so that future handlers can verify the
authenticity of both evidence and custody.
Custody refers to when any Internet Mail handler processes a message.
(Applicability of the term does not depend on ARC, or at least it
shouldn't.)
ARC provides a means of /authenticating/ custody.
*** MAJOR ***
ARC does /not/ allow verifying the authenticity of earlier 'evidence',
other than the evidence of handling signatures. That is, assertions
about prior validations are not really 'evidence'.
This is a persistent point of confusion about ARC and I consider it
serious.
Using ARC requires developing trust in the handlers that make these ARC
assertions of earlier validity. This is quite different from a later
handler 'verifying' that validity, since it can't.
*** ***
2.3. Chain of Custody
The "chain of custody" of ARC is the entire set of evidence and
custody that travels with a message.
2.4. Validation of Chain of Custody
Any ARC-enabled Internet Mail Handler can validate the entire set of
evidence and custody to yield a valid Chain of Custody. If the
No, it can validate who made what assertions -- and in what order -- not
that the assertions were valid.
evidence-supplying Custodians can be trusted, then the validated
Chain of Custody describes the (possibly changing) authentication
state as the message traveled through various Custodians.
It can validate statements about authentication, not the actual
state/correctness of those statements.
Even though a message's authentication state might have changed, the
validated chain of custody can be used to determine if the changes
(and the Custodians responsible for the changes) can be tolerated.
3. Terminology and Definitions
This section defines terms used in the rest of the document.
Readers should to be familiar with the contents, core concepts, and
definitions found in [RFC5598]. The potential roles of
intermediaries in the delivery of email are directly relevant.
The term 'intermediaries' does not appear in 5598. Nor does a term like
'intermediate handler'. Worse, the document here probably needs a term
that covers both regular MTAs AND delivery/re-posting agents such as
mailing lists, which is what RFC 5598 calls 'mediators'.
I was going to suggest just saying 'handler' or the like but RFC 5598
uses the word differently.
So the best I can suggest from RFC 5598 is 'transit service' which ought
to cover both regular MTA service and upper-level services like mailing
lists.
Andersen, et al. Expires January 18, 2019 [Page 5]
Internet-Draft ARC-Protocol July 2018
Language, syntax (including some ABNF constructs), and concepts are
imported from DKIM [RFC6376]. Specific references to DKIM are made
throughout this document. The following terms are imported from
[RFC5598]:
o ADministrative Management Domain (ADMD), Section 2.3
o Message Transfer Agents (MTA), Section 4.3.2
o Message Submission Agent (MSA), Section 4.3.1
o Message Delivery Agent (MDA), Section 4.3.3
Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405].
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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
3.1. ARC Set
Section 4.1 introduces three (3) ARC header fields. Together, the 3
fields
->
fields that are added to a message by an ARC transit system.
(That is, an arc set is a specific instance, not the abstraction that
defines those 3 fields.)
header fields compose a single "ARC Set". An ARC Set provides the
means for an Internet Mail Handler to attach authentication state to
a message in a manner that can be verified by future handlers. A
single message can contain multiple ARC Sets.
In General Concept terms, an ARC Set represents Evidence and Custody.
3.2. Authenticated Received Chain (ARC)
The complete sequence of ARC Sets attached to a message is called the
Authenticated Received Chain. An Authenticated Received Chain is a
recording of individual authentication states as a message traverses
through ARC-participating ADMDs.
"The complete sequence"
Hmmm... /What/ complete sequence? Do you mean the complete sequence
attached to a message at any one point during transit? Or do you mean
the complete sequence attached to the message after final delivery? Or...?
(On reflection, I suggest calling a sequence under development -- that
is, one being built during transit -- a 'partial sequence' and save
'complete sequence' to refer to what exists after final delivery.)
The first attachment of an ARC Set to a message causes an
Authenticated Received Chain to be created. Additional attachments
of ARC Sets cause the Authenticated Received Chain to be extended.
Andersen, et al. Expires January 18, 2019 [Page 6]
Internet-Draft ARC-Protocol July 2018
In General Concept terms, an Authenticated Received Chain represents
Chain of Custody.
3.3. Sealer
A Sealer is an Internet Mail Handler that attaches a complete and
valid ARC Set to a message.
In General Concept terms, a Sealer adds Evidence and proof of Custody
to the Chain of Custody.
Might be worth explaining why the term 'signer' isn't sufficient for
this, since a reader will likely think it the more natural choice.
3.4. Validator
A Validator is an ARC-enabled Internet Mail Handler that evaluates an
Authenticated Received Chain for validity and content. The process
of evaluation of the individual ARC Sets that compose an
Authenticated Received Chain is described in Section 5.2.
In General Concept terms, a Validator inspects the Chain of Custody
to determine the content and validity of individual Evidence supplied
by Custodians.
3.5. Imported ABNF Tokens
The following ABNF tokens are imported:
o tag-list ([RFC6376] section 3.2)
o authres-payload ([I-D-7601bis] section 2.2)
o cfws ([RFC5322] section 3.2.2)
3.6. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";"
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status
Over the years, I've come to believe that good ABNF formatting aids
readers quite a bit. So I suggest something like:
position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position [CFWS] ";"
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status
<< stopped here. /d >>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
