Subject: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-14

From: Dave Crocker <[email-masked]>
Date: Fri, 18 May 2018 14:00:57 -0700

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-masked], 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