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

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2017 18:19:34 -0700

Review of:    draft-ietf-dmarc-arc-protocol-08
Reviewed by:  D. Crocker
Review date:  27 July 2017

Summary:

ARC essentially takes the basic technology of DKIM and modifies it to 
support an integrated sequence (ordered chain) of signatures by 
successive message handling intermediaries.  The essential purpose of 
ARC is to develop a secondary foundation of message accountability, if 
the primary foundation -- authentication of the originating service -- 
fails.

The overall structure of the specification seems reasonable, except that 
signing should be covered before verifying, and the 'implementation 
status' section should be in the appendix (even though it's marked for 
removal.)

The document suffers a predictable problem, given that it builds upon 
existing documentation: it forces the reader to jump back and forth 
between the existing documents and the current specifications.  Worse, 
it often does not supply enough detail in references to make this 
cross-referencing easy.  Also worse is that it sometimes seeks to 
summarize or re-state normative text from the existing documentation, 
thereby running the risk of inaccuracies or divergence.

Sometimes the document contains language purporting to be normative but 
lacking technical detail.  Typically, these really are mild advisories 
and should be altered to softer language or even removed.  The basic 
question that needs to be asked repeatedly throughout the text is: how 
will a new implementer be able to use this text to produce reliably 
interoperable software?

The document seems to mix protocol specification with development 
guidance and operations guidance.  It needs to separate these much 
better and distinguish them more carefully.

I thought an essential motivation for ARC was to create a signature that 
would be more survivable than a simple DKIM signature.  Perhaps that's 
no longer the case and that, rather, the goal is simply to create a 
/replacement/ (set of) signature(s), after breaking the original.  The 
intro to the spec should make a clear, direct, simple statement about this.

There are some portions of the document that seems to be modifying DKIM 
or SMTP, such as specifying SMTP response behavior.  While I know that 
DKIM did this about SMTP, too, I suggest refraining from it here: 
Specify and ARC engine and an overall ARC service that has inputs, 
processing and output.  Don't specify how those outputs are used.

d/

Detailed Comments:

(these are, essentially, stream of conscious and include high-level and 
nit-picking detailed comments mixed together, essential and trivial. /d)

> Abstract
> 
>    The Authenticated Received Chain (ARC) protocol creates a mechanism
>    whereby a series of handlers of a message can conduct authentication
>    of a message as it passes among them on the way to its destination,
>    and record the status of that authentication at each step along the
>    handling path, for use by the final recipient in making choices about
>    the disposition of the message.

'authentication of a message' has a formal correctness but problematic 
effect.  It encourages misinterpreting the mechanism as 'validating' 
message content.  We already see this regularly, such as about DKIM, so 
we should avoid language that encourages more of it.

The summary should provide a careful, constrained statement of the 
narrow functionality that ARC provides. I suggest something along the 
lines of what I offer, below, as "Replace An Authenticated with:".

> Table of Contents

Overall, the organization looks reasonable.

>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>    3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
>    4.  Instance ('i=') Tags  . . . . . . . . . . . . . . . . . . . .   5
>      4.1.  Valid Range for Instance Tags . . . . . . . . . . . . . .   6
>    5.  The ARC Header Fields . . . . . . . . . . . . . . . . . . . .   6
>      5.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . . . .   6
>        5.1.1.  Additional Information for the AAR Header . . . . . .   7
>      5.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . . . .   7
>      5.3.  ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . .   8
>        5.3.1.  The 'cv' Tag  . . . . . . . . . . . . . . . . . . . .   9
>        5.3.2.  Selected Header Fields  . . . . . . . . . . . . . . .   9
>    6.  Verifier Actions  . . . . . . . . . . . . . . . . . . . . . .   9

Seems odd to have verifier before signer.

>    7.  Signer Actions  . . . . . . . . . . . . . . . . . . . . . . .  11
>    8.  Key Management  . . . . . . . . . . . . . . . . . . . . . . .  12
>    9.  Usage of ARC and Chain Validity . . . . . . . . . . . . . . .  12
>      9.1.  Relationship between DKIM-Signature and AMS signing
>            scopes  . . . . . . . . . . . . . . . . . . . . . . . . .  12
>      9.2.  Assessing Chain Validity Violations . . . . . . . . . . .  12
>      9.3.  Marking and Sealing "cv=fail" (Invalid) Chains  . . . . .  12
>      9.4.  Handling DNS Problems While Validating ARC  . . . . . . .  13
>      9.5.  Responding to ARC Validity Violations . . . . . . . . . .  13
>      9.6.  Recording the Results of ARC Evaluation . . . . . . . . .  13
>        9.6.1.  Output Information from an ARC Evaluation . . . . . .  13
>        9.6.2.  Reporting ARC Effects for DMARC Local Policy -
>                Interim . . . . . . . . . . . . . . . . . . . . . . .  14
>    10. Supporting Alternate Signing Algorithms . . . . . . . . . . .  14
>      10.1.  Introductory Period  . . . . . . . . . . . . . . . . . .  15
>      10.2.  Co-Existence Period  . . . . . . . . . . . . . . . . . .  15
>      10.3.  Deprecation Period . . . . . . . . . . . . . . . . . . .  15
>      10.4.  Obsolescence Period  . . . . . . . . . . . . . . . . . .  15
>    11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
>    12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
>      12.1.  Authentication-Results Method Registry Update  . . . . .  15
>      12.2.  Definitions of the ARC header fields . . . . . . . . . .  16
>    13. Implementation Status . . . . . . . . . . . . . . . . . . . .  17

This section should be moved to an Appendix, even though it's marked for 
removal upon publication.

>      13.1.  GMail test reflector and incoming validation . . . . . .  17
>      13.2.  AOL test reflector and internal tagging  . . . . . . . .  18
>      13.3.  dkimpy . . . . . . . . . . . . . . . . . . . . . . . . .  18
>      13.4.  OpenARC  . . . . . . . . . . . . . . . . . . . . . . . .  18
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 2]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>      13.5.  Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . .  19
>      13.6.  Copernica/MailerQ web-based validation . . . . . . . . .  20
>      13.7.  Rspamd . . . . . . . . . . . . . . . . . . . . . . . . .  20
>      13.8.  PERL Mail::Milter::Authentication module . . . . . . . .  21
>    14. Security Considerations . . . . . . . . . . . . . . . . . . .  21
>      14.1.  Message Content Suspicion  . . . . . . . . . . . . . . .  22
>    15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
>      15.1.  Normative References . . . . . . . . . . . . . . . . . .  22
>      15.2.  Informative References . . . . . . . . . . . . . . . . .  24
>      15.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  25
>    Appendix A.  Appendix A - Example Usage (Obsolete but retained
>                 for illustrative purposes) . . . . . . . . . . . . .  25
>      A.1.  Example 1: Simple mailing list  . . . . . . . . . . . . .  25
>        A.1.1.  Here's the message as it exits the Origin:  . . . . .  25
>        A.1.2.  Message is then received at example.org . . . . . . .  26
>        A.1.3.  Example 1: Message received by Recipient  . . . . . .  28
>      A.2.  Example 2: Mailing list to forwarded mailbox  . . . . . .  29
>        A.2.1.  Here's the message as it exits the Origin:  . . . . .  29
>        A.2.2.  Message is then received at example.org . . . . . . .  30
>        A.2.3.  Example 2: Message received by Recipient  . . . . . .  34
>      A.3.  Example 3: Mailing list to forwarded mailbox with source   36
>        A.3.1.  Here's the message as it exits the Origin:  . . . . .  36
>        A.3.2.  Message is then received at example.org . . . . . . .  37
>        A.3.3.  Example 3: Message received by Recipient  . . . . . .  42
>    Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  44
>    Appendix C.  Comments and Feedback  . . . . . . . . . . . . . . .  45
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45
> 
> 1.  Introduction
> 
>    Modern email authentication techniques such as the Sender Policy
>    Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
>    [RFC6376] have become ubiquitious.  However, they are stymied by a

ubiquitous

>    small number of common applications, most notably mailing list
>    managers, as these applications have handling properties that prevent
>    these authentication schemes from universal effectiveness.  These

Replace the However sentence with:

      However, their end-to-end utility is limited by the effects of 
intermediaries along the transmission path, which either are not 
registered (for SPF) or which break digital signatures (for DKIM).

>    issues are described in substantial detail in those protocols'
>    defining documents as well as in [RFC6377] and [RFC7960].
> 
>    In an effort to reduce the success of fraudulent email campaigns,
>    there has been an effort to develop and deploy technologies that use
>    SPF and DKIM to assure legitimate use of the identity of the apparent
>    message author, i.e., the visible "From:" field in a message.  To

Replace first and second sentences with:

    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 Compliance (DMARC) [RFC7489], ensures 
legitimate use of the rfc5322.From author header field, by validating 
the domain name used in its address.

>    this end, Domain-based Mail Authentication, Reporting and Compliance
>    (DMARC) [RFC7489] has been developed and deployed.  However, its
>    deployment in environments where mailing lists are used has had the
>    negative impacts predicted in the documents listed above.

Consider replacing However with:

    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 and for those they are interacting with.

> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 3]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    What is needed is a mechanism by which legitimate alteration of a
>    message, invalidating SPF and DKIM, does not ultimately result in a

    invalidating SPF and DKIM
    ->
    which invalidates associated SPF and DKIM information

>    rejection of an email message on delivery.  An Authenticated Received
>    Chain (ARC), described here, provides a superset of the functionality
>    of DKIM in order to provide to the message recipient system(s) a more
>    complete view into the handling chain of a message and the points in
>    that chain where alterations of the content may have occurred.

Replace An Authenticated with:

    Authenticated Receive Chain (ARC) builds upon DKIM mechanisms, to 
provide a sequence of signatures that are more survivable than DKIM's 
and 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 information, the recipient system(s)
>    can make a more informed handling choice, reducing or eliminating the
>    false postives inherent in use of DKIM and/or SPF themselves.

    positives

> 2.  Overview
> 
>    In DKIM, every participating signing agent attaches a signature that

   content -> some content

(there continues to be a misunderstanding of what the signature covers; 
so a bit of qualifying language is needed.)

>    is based on the content of the message, local policy, and the domain
>    name of the participating Administrative Management Domain (ADMD).
>    Any verifier can process such a signature; a verified signature means

      ...a verified signature means that the domain referenced in the 
DKIM-Signture: "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 message content that was "covered" by the signature has not been
>    altered since the signature was applied.  The signatures themselves
>    are generally independent of one another.

That last sentence is true, of course, but I think I don't know what it 
actually means or, more importantly, what it intends to imply.

> 
>    By contrast, this protocol seeks to have each signature be able to

    this protocol seeks to have each signature be able to convey
    ->
    an ARC signature conveys

>    convey the following pieces of information:
> 
>    1.  An assertion that, at the time that the intermediary ADMD
>        processed the message, the various assertions already attached to
>        the message by other ADMDs were or were not valid;

"the various assertions"  hmmm.  Too vague and broad, since it won't 
cover random other specifications that are created later.  So while it's 
a pain, this text needs to be more specific.  I that what is meant here 
is only and specifically that a particular DKIM signature, which now is 
probably broken, validated.

I'm not clear about precise, formal security geek language, but I think 
that a signature is not an 'assertion'...?  (This is a nit-picky concern 
about overloading a term of art.)

> 
>    2.  As with DKIM, an assertion that, for a passing signature, the

    passing -> validated

>        domain name in the signature takes some responsibility for
>        handling of the message and that the message is unchanged since
>        that signature was applied;
> 
>    3.  A further assertion that combines and protects the above against
>        alteration by later handlers.

I think I don't know what this means, especially the idea than an 
assertion can create protection.

> 
>    This protocol accomplishes each of these by adding a new header field
>    to the message for each of them, as follows:

  "of them"?  who is being referenced?

Perhaps:

    ARC accomplishes these by having each later handler add a new header 
field to the message.

(except that it doesn't have to be each new handler, does it?  only 
some... hmmm... )

> 
>    o  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 added to this field compared to a
>       standard Authentication-Results field in order to support a more
>       complete DMARC report (see Section 5.1);

    added to this field compared to a standard Authentication-Results
    ->
    placed in this field

> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 4]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    o  ARC-Message-Signature (referred to below as "AMS"): virtually
>       identical in syntax to DKIM-Signature, this field contains the
>       assertions about the message header and body as they existed at
>       the time of handling by the ADMD adding it; and

assertions?

> 
>    o  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.
> 
>    A distinguishing feature of all of these is that an ARC participant

    participant -> signer

>    always adds all of them before relaying a message to the next

I don't understand what is being distinguished here, since they aren't 
going to add the fields /after/ relaying.

>    handling agent en route to its destination.  Moreover, as described
>    in Section 4, they each have an "instance" number that increases with
>    each ADMD in the handling chain so that their original order can be
>    preserved and the three of them can be processed as a group.

    of them -> related header fields

Hmmm.  DKIM does it's signing with only a single field.  ARC requires 
-Seal and -Message-Signature.  It isn't clear why two different 
signature fields are required.

> 3.  Terminology

In this case, the section should be "Definitions and Terminology" since 
it's also the place for importing spec details from other specs.

For a specification like this, that builds upon a number of existing 
documents, the challenge for the writer is to avoid creating redundant 
text that risks divergence from the original specification.  The 
challenge for the reader is to find the definition of a term, without 
having to search across the multiple, underlying documents.  To this 
end, I suggest listing here the terms that are being imported, citing 
what document (and section) they come from, but without re-defining 
them.  So, for example:

    ADMD - [RFC5598], Section 2.3
    MTA - [RFC5598], Section 4.3.2
    MSA - [RFC5598], Section 4.3.1
    MDA - [RFC5598], Section 4.3.3

>    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", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
>    Readers are encouraged to be familiar with the contents of [RFC5598],
>    and in particular, the potential roles of intermediaries in the
>    delivery of email.

The doc relies on terminology from 5598, so you are doing more than 
encouraging.

> 
>    Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
> 
>    A single group of the header fields introduced in Section 2 is called
>    an "ARC set", and the complete sequence of these groups is called an
>    "Authenticated Received Chain" or merely an "ARC chain".  Although
>    the "Received" header field is typically not included in the signed
>    content, the name is based on the notion that this is in essence a
>    cryptographically signed series of header fields that attest to the
>    handling chain of a message much as Received fields always have.

Stylistic nit:  When defining/explaining terms, use a hanging indent 
format, starting with the term, so the terms being defined stand out 
visually.

This spec imports language, syntax, and other details from DKIM.  That 
importation should be specified here. (RFC6376).

> 4.  Instance ('i=') Tags
> 
>    The header fields comprising a single ARC set are identified by the
>    presence of a string in the value portion of the header field that
>    complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
>    The tag-name is always the single character "i" and the value is the
>    text representation of a positive integer, indicating the position in

    Tags -> Tag (?)

The 'is always' phrasing is odd.  Rather:

   The tag-name is "i" and the value is the ...

> 
> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 5]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    the ARC sequence this set occupies, where the first ARC set is
>    numbered 1.  In ABNF terms:
> 
>       instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"

For referential benefit, I'm be inclined to suggest:

         instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"

         position = 1*DIGIT

>    At any delivery stage, it is an error if any ARC set is invalid
>    (i.e., does not contain exactly one of the three header fields

This sentence is out of place and it's import is unclear.  It refers to 
the set rather than to i=; so it shouldn't be in this section.  And 
there's no basis, yet, for knowing what 'an error' means in terms of 
processing ARC.  The essential point here is simply that a valid set 
MUST contain all three header fields.

>    defined by this protocol).  (Note that when multiple algorithms are
>    supported, there is some nuance to this statement - see Section 10.)
> 
>    Note that because the AMS and AS header field values are made 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
>    initial position for convenience.  Implementers SHOULD seek to start
>    with the i= tag to facilitate human inspection o f the headers.

The SHOULD is formally inappropriate, since the behavior is, by the 
earlier language, not normative.  So, downgrade the language to 
'encouraged' or somesuch.

> 
> 4.1.  Valid Range for Instance Tags
> 
>    The 'i' tag value can range from 1-1024 (inclusive).

Why 1024?

>    ARC implementations MUST support at least ten (10) intermediary
>    steps.

I think this is meant to say 'ten (10) ARC sets.'

>    More than fifty (50) intermediaries is considered extremely unlikely
>    so ARC chains with more than fifty intermediaries may be marked with
>    "cv=fail".

   may -> MAY

Still, this is odd language for a specification, since its 
non-determinimism ensures inconsistent behavior across implementation. 
That always produces non-interoperability.

Define a firm limit.  Enforce it.

Or...

Absent the ability to agree on that limit, indicate that the operational 
limit, if any, will be developed through field experience and documented 
separately.  Or somesuch.

> 5.  The ARC Header Fields
> 
>    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.

This paragraph belongs in terminology and definitions, listing the specs 
that are drawn from.  That provides enough context so the details, 
below, just need to cite their base document as is done.

> 
> 5.1.  ARC-Authentication-Results (AAR)
> 
>    The ARC-Authentication-Results header field is defined.  It is

    [defined. It is] remove

>    syntactically and semantically identical to an Authentication-Results
>    header field [RFC7601] (A-R), as is the mechanism by which it is
>    constructed, with the following exception:

IETF specs do not dictate implementation and therefore do not specify 
mechanisms for construction.  So I don't know what is meant by such 
phrasing here.  I suspect that the 'as is' clause should be removed.

>    o  There is an "i" tag, as described in Section 4; and
> 
>    o  Two (or more) additional pieces of information MAY be added (see
>       Section 5.1.1).
> 
>    The instance identifier MUST be separated from the rest of the
>    Authentication-Results value contents with a semi-colon (';', 0x3b).
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 6]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    The purpose of this header field is to incorporate into the record
>    the success or failure of any authentication done on the message
>    upstream of the participating ADMD, to validate and continue the
>    authentication chain.

    the participating ADMD, to validate and continue
    ->
    the participating ADMD that is validating and continuing

> 
>    In processing, some architectures will generate multiple A-R records

"some architectures" ?  What does this mean?  Perhaps simply some 
participating ADMDs?

>    for the same authserv-id.  In such cases, the resinfo value from each
>    of the A-R records should be concatenated into a single record just
>    as they would have been if they were generated in a single A-R
>    record.

'should'?  is that meant normatively?  if not, this would be a good 
place for a different word.

> 
> 5.1.1.  Additional Information for the AAR Header
> 
>    An ARC signer generates this field in the same way that a
>    conventional A-R field would be generated.  Because the AAR is

"the same way"?  what does this mean? sounds implementation-ish and in 
any event provides no specification (or even implementation) detail.

>    designed for machine-based consumption over the course of a message's
>    transit through a series of mediators and to facilitate
>    troubleshooting of problematic sources by sending organizations,

This 'because' statement appears to be asserting justification that has 
no foundation in the document (or at least not so far.)  Also reference 
to machine consumption isn't very helpful, since nearly all of these 
specs are to produce machine-processable data.

The phrase 'troubleshooting of problematic sources by sending 
organizations' is confusing, since sources do sending.

My best guess for improving this:

    1. In the intro to AAR, explain what its purpose(s) is (are).

    2. In 5.1 explain how it is achieves those purposes.

    3. In 5.1.1 simply say something like:

       Troubleshooting problematic ADMDs that are participating in ARC is
       aided by including the following trace information:

>    three additional fields of data SHOULD be added to the normal A-R
>    content, dependent on the presence of DKIM-Signature and/or ARC
>    set(s) and if available to the ADMD which is recording the A-R:
> 
>    o  source.ip - The connecting client IP address from which the
>       message is received; and

if you want to save a couple of characters:

    source -> src

>    o  header.s - The selector value associated with each dkim signature
>       (added to the dkim data sections of the A-R/AAR record)

That's far too generic.

I suggest naming this more meaningfully and intuitively, such as:

    dkim.sel

>    o  ARC-related data (added to the arc data sections of the A-R/AAR
>       record):
> 
>       *  ams[N].d - The domain value associated with the 'N'th ARC set's
>          AMS header
> 
>       *  ams[N].s - The selector associated with the 'N'th ARC set's AMS
>          header
> 
>       *  as[N].d - The domain value associated with the 'N'th ARC set's
>          AS header
> 
>       *  as[N].s - The selector associated with the 'N'th ARC set's AS
>          header

     header -> header field

> 5.2.  ARC-Message-Signature (AMS)
> 
>    The ARC-Message-Signature header field is defined.  It is
>    syntactically and semantically identical to a DKIM-Signature header

    The ARC-Message-Signature header field is defined.  It is
    ->
    The ARC-Message-Signature header field is

> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 7]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    field [RFC6376], as is the mechanism by which it is constructed, with
>    the following exceptions:

   [as is the mechanism by which it is constructed,] delete

>    o  There is an "i" tag, as described in Section 4.
> 
>    o  There is no "v" tag.
> 
>    ARC-Seal header fields MUST never be included in the content covered
>    by the signature in this header field.

    MUST never -> MUST NOT

>    The AMS SHOULD include any DKIM-Signature header fields already
>    present on the message in the header fields covered by this
>    signature.
> 
>    The AMS header field MAY inclue (sign) the AAR header field(s).

    inclue  -> include

>    Authentication-Results header fields SHOULD NOT be included since
>    they are likely to be deleted by downstream ADMDs (per Section XXX of
>    [RFC7601]), thereby breaking the AMS signature.
> 
>    As with a DKIM-Signature, the purpose of this header field is to
>    allow the ADMD generating it to take some responsibility for handling
>    this message as it progresses toward delivery.

What is the logic for the various MUST, SHOULD and MAY directives about 
inclusion?  What are the downsides of not following the SHOULD or MAY?

> 5.3.  ARC-Seal (AS)
> 
>    The ARC-Seal header field is defined.  It is syntactically and
>    semantically similar to a DKIM-Signature field, with the following
>    exceptions:

    The ARC-Seal header field is defined.  It is
    ->
    The ARC-Seal header field is

>    o  There is an "i" tag, as described in Section 4.
> 
>    o  The ARC-Seal covers none of the body content of the message.  It
>       only covers specific header fields.  (See below: Section 5.3.2.)
>       As a result, no body canonicalization is done.  Further, only
>       "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
>       used.
> 
>    o  The only supported tags are "i" (Section 4 supercedes the
>       [RFC6376] definition), and "a", "b", "d, "s", "t".  The latter 5
>       tag definitions are copied from Section 3.5 of [RFC6376].
> 
>    o  An additional tag, "cv" is defined.  (See below: Section 5.3.1)
> 
>    The purpose of this field is to assure the integrity of the ARC set
>    being added by the ADMD generating this header field, and moreover to
>    ensure no tampering with the ARC overall.

This explanation is redundant with the explanation in the defining 5.3.1 
section (or, at least, it should be) and hence is not needed.  Remove 
it.  Redundant text invites divergence.

> Andersen, et al.        Expires January 22, 2018                [Page 8]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
> 5.3.1.  The 'cv' Tag
> 
>    A new tag "cv" (chain validation) is defined, which indicates the
>    state of the ARC chain as evaluated when it arrived at the ADMD
>    adding this header field.  It accepts one of three possible values:

    A new tag "cv" (chain validation) is defined, which indicates
    ->
    The tag "cv" (chain validation) indicates

    the
    state of the ARC chain as evaluated when it arrived at the ADMD
    adding this header field.
    ->
    the outcome of evaluating the existing ARC chain upon arrival at the
    ADMD that is adding this header field.

>    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) from a Message Submission Agent (MSA) or when
>       any upstream MTAs 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.
> 
>    In ABNF terms:
> 
>     seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
> 
> 5.3.2.  Selected Header Fields
> 
>    The ARC-Seal signature is an encryption of the hash of the
>    concatenation of the canonicalized form of the ARC sets present on
>    the message at the time of sealing, in increasing instance order,
>    starting at 1, including the one being added at the time of sealing
>    the message.

The above paragraph appears to be the only actual 'detailed' 
specification of what an ARC signature is, and it is both obscure and 
too dense.  It needs to be re-formed into an algorithm specification.  I 
suspect it also needs to be moved to the section on signing.

> 
>    Within a set, the header fields are presented in the following order:

   presented -> listed

>    1.  ARC-Authentication-Results
> 
>    2.  ARC-Message-Signature
> 
>    3.  ARC-Seal
> 
>    Where the ARC-Seal is the one being generated, it is presented 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.

    presented -> added (or input)

>    Note that the signing scope for the ARC-Seal is modified in the
>    situation where a chain has failed validation (see Section 9.3).
> 
> 6.  Verifier Actions
> 
>    The verifier takes the following steps to determine the current state
>    of the ARC on the message:

state of the ARC?  perhaps ARC /chain/ or ARC signature chain?

> 
> 
> 
> Andersen, et al.        Expires January 22, 2018                [Page 9]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    1.  Collect all ARC sets currently on the message.  If there were
>        none, the ARC state is "none" and the algorithm stops here.
> 
>    2.  If any ARC set is invalid (e.g., does not contain exactly one of
>        each of the three ARC-specific header fields), then the chain
>        state is "fail" and the algorithm stops here.

    If any ARC set -> If the form of any ARC set

This step is not doing computational validation; that's steps 3 & 4.  So 
I assume this step is for basic, structural validation.  Essentially a 
kind of syntax check.

> 
>        1.  To bypass all cryto and DNS operations, the cv value for all
>            ARC-Seal(s) MAY be checked at this point.  If any of the
>            values are "fail", then the overall state of the chain is
>            "fail" and the algorithm stops here.

    cryto -> crypto

The 'bypass' sentence confused me a bit.  I think what is intended is 
something like:

    To avoid the overhead of unnecessary computation and delay, the cv=
    value for all existing ARC-Seals MAY be checked at this point. If ...

>    3.  Conduct verification of the ARC-Message-Signature header field
>        bearing the highest instance number.  If this verification fails,
>        then the chain state is "fail" and the algorithm stops here.
> 
>    4.  For each ARC-Seal from the "N"th instance to the first, apply the
>        following logic:

Having subordinate numbering be the same style as the superior could be 
confusing.  Readability would be improved by using a different style. I 
suggest switching to lower case letters. An alternative would be 
two-part numbering.  So the one below here would be 4.1. (And I see that 
that's the notation already in use in this next entry...)

>        1.  If the value of the "cv" tag on that seal is "fail", the
>            chain state is "fail" and the algorithm stops here. (note
>            that this duplicates step 2.1)

I suggest replacing the 'note' text with:

    This step MAY be skipped, if the earlier, step 2.1 was performed.

(And the MAY probably should be SHOULD...)

> 
>        2.  In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
>            == "none" && i != 1)) then the chain state is "fail" and the
>            algorithm stops here.

Why is the i/cv ordering swapped for the two tests?

>        3.  Prepare a hash function corresponding to the "a" tag of the
>            ARC-Seal.

Where are the technical details for producing the hash formally 
supplied?  Cite them here.  And what does the 'corresponding to the "a" 
tag of the ARC-Seal' mean?

>        4.  Compute the canonicalized form of the ARC header fields, in
>            the order described in Section 5.3.2, using the "relaxed"
>            header canonicalization defined in Section 3.4.2 of
>            [RFC6376].  Pass them to the hash function.

"Pass them to the hash function."? This appears to be specifying input 
to a function that was performed (and presumably finished) in the 
preceding step.

>        5.  Retrieve the final digest from the hash function.

So I'm guessing that steps 4.3 - 4.5 are meant as a sub-function, but 
nothing makes that explicit.  At the least, 4.3 should say 'Start' 
rather than 'Prepare" and possibly the substeps should have sub-numbering.

>        6.  Retrieve the public key identified by the "s" and "d" tags in
>            the ARC-Seal, as described in Section 8.
> 
>        7.  Determine whether the signature portion ("b" tag) of the ARC-
>            Seal and the digest computed above are valid according to the
>            public key.

How is this to be determined?

>        8.  If the signature is not valid, the chain state is "fail" and
>            the algorithm stops here.
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018               [Page 10]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    5.  If all seals pass validation, then the chain state is "pass", and
>        the algorithm is complete.
> 
>    The verifier should record the cv state for subsequent use by any
>    sealing which may be done later (potentially after message
>    modification) within the same trust boundary.  The cv state may be
>    recorded by sealing at the time of verification in an initial ARC set
>    (for the ADMD) or may be recorded out of band depending on the
>    architecture of the ADMD.

To avoid misunderstanding, I suggest altering the first sentence to 
something like:

    Save the cv state, for possible use by...

    The cv state may be -> The cv state MAY be

But really, that entire sentence should be deleted.  It is not provided 
specification detail and the implementation guidance is minimal at best.

> 7.  Signer Actions

This section appears to be the very broad strokes of implementation 
guidance, rather than the details of a protocol specification.  It's not 
clear what benefit this is supposed to provide, but it doesn't seem to 
have much to do with the semantics or interoperability of ARC.

>    This section includes a walk-through of the actions an ARC signing
>    implementation takes when presented with a message.

    walk-through -> specification

Except that this doesn't really read like a formal specification, yet 
one is needed.

    signing implementation -> signer

>    The signing agent should undertake the following steps:

   should ->? SHOULD

but why not MUST?

>    1.  Do any authentication steps that the ADMD normally does:

huh? /any/? What does this mean?  Why is it relevant to this 
specification?  How is it used?

>        1.  If a message is traveling within the same trust boundary,
>            this would include any internal trust conveyed with the
>            message;

   ; -> .

>        2.  If a message is coming from outside the same trust boundary,
>            this would include any SPF / DKIM / DMARC / other
>            authentication evaluation steps.

This document is not a specification or BCP for ADMD authentication.  So 
1.1 and 1.2 really are out of scope (as well as providing inadequate 
technical detail to be useful.)

>    2.  Do any DKIM signing or authentication assertion steps that the
>        ADMD normally does.

I suspect that 1 and 2, above, should be replaced with some simple 
introductory text that says something like:

    Before creating an ARC signature, perform any other, normal 
authentication and/or signing, so that the ARC signature can cover the 
results with this additional information.

>    3.  Generate and optionally attach to the message an Authentication-
>        Results header field using the ADMD's authserv-id (see
>        Section 2.5 of [RFC7601]) indicating whatever authentication
>        might have been done by the MTA, or possibly indicate that none
>        was done.

optionally?  I suspect it's not optional, if they are participating in 
ARC (and especially not if it's been generated.  What benefit is there 
in generating it if it is not then attached?)

same concern for 'possibly'.   This text needs to be cast into normative 
specification language appropriate to a participant in ARC.

>    4.  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.
>
>        2.  Generate and attach to the message an ARC-Authentication-
>            Results header field using instance number N+1 and the same
>            content from the previous step.
>
>        3.  Generate and attach to the message an ARC-Message-Signature
>            header field using the general algorithm described in

    [general] delete

> 
> 
> Andersen, et al.        Expires January 22, 2018               [Page 11]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>            Section 5 of [RFC6376] and as modified in Section 5.1 above,
>            using instance number N+1.
  and -> ,

>        4.  Generate and attach to the message an ARC-Seal header field
>            using the general algorithm described in Section 5.3 above,
>            the chain validation status as determined in Section 6, and
>            instance number N+1.

   [general] delete

> 8.  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].  Operators may use distinct selectors and/
>    or domains for the ARC header fields at their own discretion.

Just to avoid the reader's thinking that the 'operators' sentence is 
normative specification, perhaps modify the last sentence to something like:

    For operational convenience, signers can choose to use selectors 
and/or domains for the ARC header field signatures that are distinct 
from those used in DKIM signing.

> 9.  Usage of ARC and Chain Validity
> 
> 9.1.  Relationship between DKIM-Signature and AMS signing scopes
> 
>    DKIM-Signatures SHOULD never sign any ARC header fields.

Oh boy.  That normative statements constitutes a formal modification to 
the DKIM specification.  While I understand the desire, I recommend 
against pursuing it this way.

Besides, I do not see the actual need for such a normative 
specification.  What is the harm in having a DKIM signature cover any 
ARC header fields?

> 9.2.  Assessing Chain Validity Violations
> 
>    There are a wide variety of ways in which the ARC set of header

   are -> is

>    fields can be broken.  Receivers need to be wary of ascribing motive
>    to such breakage although patterns of common behaviour may provide
>    some basis for adjusting local policy decisions.

If a reader needs this instruction, the probably need a bit more 
background that the first sentence gives.  Perhaps:

    Email transit can produce broken signatures for a wide variety of 
benign reasons.  This includes possibly breaking one or more ARC 
signatures.  Therefore, receivers need to be wary of ascribing malign 
motives to such breakable...

>    This specification is exclusively focused on well-behaved,
>    participating intermediaries that result in a valid chain of ARC-
>    related header fields.  The value of such a well-formed, valid chain
>    needs to be interpreted with care since malicious content can be
>    easily introduced by otherwise well-intended senders through machine
>    or account compromises.  All normal content-based analysis still
>    needs to be performed on any messages bearing a valid chain of ARC
>    header sets.

First, the paragraph is self-contradictory, since it concern 
non-well-behaved activities.

Second, this is problematic text.  Not because it's wrong but because it 
says far too little.  It raises a concern, without really explaining its 
basis and without giving useful guidance about what to do to compensate 
for the (possible) problem.

I'm guessing about what the underlying issues are, here, but here's an 
attempt:

    ARC does not attempt to protect and entire message.  There are 
various ways that a message can still be problematic, in spite of having 
a valid ARC chain.  Consequently, all normal, content-based analysis 
SHOULD still be performed on any message having a valid chain of ARC 
header sets.

> 
> 9.3.  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 'i=' instance headers
>    created by the MTA which detected the malformed chain, as if this
>    newest ARC set was the only set present.

Hmmm.  is 'signed by' the correct characterization?  I'm asking this as 
a real question and as a nit about formal language, not really a major 
concern about reader understanding.

> 
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018               [Page 12]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
> 9.4.  Handling DNS Problems While Validating ARC
> 
>    DNS failures to resolve or return data which is needed for ARC
>    validation SHOULD result in a 421 tempfail during the SMTP
>    conversation with the sending system.  Temporary or intermittent DNS
>    problems will generally not be sufficiently transitory to allow a
>    mediator to obtain a different result during the ordinary transit
>    duration so it is better to have the source system queue the
>    problematic message(s) than to generate (potential) backscatter.
> 
>    Operators of systems which mediate mail should be aware that broken
>    DNS records (or malfunctioning name servers) will result in
>    undeliverable mail to any downstream ARC-verifying ADMDs.
> 
>    DNS-based failures to verify a chain are treated no differently than
>    any other ARC violation.  They result in a "cv=fail" verdict.

Hmmm.  This section seems to be inviting two kinds of problems: 
directing SMTP behavior and directing interpretation of DNS behaviors.

I suggest, instead that the ARC protocol engine be defined in terms of 
temporary failures and permanent failures and then specify what causes 
each.  How the containing email system should handle those two types of 
failures should be out of scope for this specification.

(I'm suggesting something different and more constrained than the DKIM 
spec does.)

> 
> 9.5.  Responding to ARC Validity Violations
> 
>    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.
> 
> 9.6.  Recording the Results of ARC Evaluation
> 
>    Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
>    a locally-affixed Authentication-Results [RFC7601] header field along
>    with any salient comment(s).

This seems to be augmenting RFC7601?

> 9.6.1.  Output Information from an ARC Evaluation
> 
>    The evaluation of a series of ARC sets results in the following data
>    which MAY be used to inform local-policy decisions:

This is an example of a gratuitous normative statement.  First, it has 
no real substance.  Second, it is out of scope of the specification. 
The spec is defining the ARC engine, input and output.  It is /not/ 
defining how the output is used.

So:

   [which MAY be used to inform local-policy decisions] delete

Given that it is the essence of ARC semantics, it might be useful for 
general consumption, to give a prose summary of this output:  Perhaps 
something like "ARC Chain evaluation produces a list of domain names for 
intermediaries that handled the message."  Or somesuch.

>    o  A list of the "d=" domains found in the validated ARC-Seal header
>       fields;

  [;] delete

>    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.
> 
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018               [Page 13]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
> 9.6.2.  Reporting ARC Effects for DMARC Local Policy - Interim

I strongly urge moving all discussion of ARC use for DMARC into an 
independent document.  Keep the basic ARC specification a basic ARC 
specification.  Make DMARC policy discussion separate.

>    [[ Note: Discussion on the IETF DMARC-WG list has indicated some
>    interest in more substantial reporting for analytic purposes.  To
>    support that effort, the following guidance is provided only as an
>    interim, minimal data set.  A more complete reporting construct will
>    be specified in a related spec - TBD. (see the additional fields
>    specified in Section 5.1.1) ]]
> 
>    Receivers SHOULD indicate situations in which ARC evaluation
>    influenced the results of their local policy determination.  DMARC
>    reporting of ARC-informed decisions is augmented by adding a
>    local_policy comment explanation containing the list of data
>    discovered in the ARC evaluation (Section 9.6.1 and Section 5.1.1):
> 
>  <policy_evaluated>
>    <disposition>delivered</disposition>
>    <dkim>fail</dkim>
>    <spf>fail <comment>source.ip=10.0.0.1</comment></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</comment>
>    </reason>
>  </policy_evaluated>
> 
>    In the suggested sample, d2.example is the sealing domain for ARC[2]
>    and d1.example is the sealing domain for ARC[1].
> 
>    Mediators 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.
> 
> 10.  Supporting Alternate Signing Algorithms
> 
>    [[ Note: Some additional development of this section is needed. ]]
> 
>    In the following branch diagrams, each algorithm is represented by an
>    'A' or 'B' at each hop to depict the ARC chain that develops over a
>    five hop scenario.  'x' represents a hop that does not support that
>    algorithm.
> 
>    Note that during a transitional period where multiple algorithms are
>    allowed, all of the statements in this spec which refer to "exactly
>    one set of ARC headers per instance" need to be understood as "at
> 
> 
> 
> 
> Andersen, et al.        Expires January 22, 2018               [Page 14]
> 
> Internet-Draft                ARC-Protocol                     July 2017
> 
> 
>    least one set per instance and no more than one instance-set per
>    algorithm".

This is an essential restriction/capability and need to be moved to be 
part of the original specification.  There are a few different ways to 
phrase this and I'm not sure which would work best.

> 
> 10.1.  Introductory Period
> 
>    Intermediaries MUST be able to validate ARC chains build with either
>    algorithm but MAY create ARC sets with either (or both) algorithm.

    build -> built

>    The introductory period should be at least six (6) months.

This has no context nor justification.  I assume the section is 
attempting to talk about the introduction of new signing algorithms and 
the need to support overlapping use of old and new and the fact that 
transitions on the Internet take a long time and a signer using a new 
algorithm needs to assume it might take awhile for all of their 
receivers to also support it and...

> 10.2.  Co-Existence Period
> 
>    Intermediaries MUST be able to validate ARC chains build with either
>    algorithm and MUST create ARC sets with both algorithms.  Chains
>    ending with either algorithm may be used for the result.

Take this out of normative mode, since it's impractical.  The whole 
reason that an extended transition period is needed is because a 
requirement like the above won't happen (and in fact can't.)

> 10.3.  Deprecation Period
> 
>    ARC sets built with algorithms that are being deprecated MAY be
>    considered valid within an ARC chain, however, intermediaries MUST
>    NOT create additional sets with the deprecated algorithm.

Where are the specifications for the procedures to register and 
deprecate algorithms?  Why aren't they cited here?

>    The deprecation period should be at least two (2) years.

I fear that this section is mostly gratuitous, since it doesn't have 
much import.  If someone thinks otherwise, would they please explain 
what effect any of this will have on developers or operators?

> 10.4.  Obsolescence Period
> 
>    ARC sets built with algorithms that are obsolete MUST NOT be
>    considered valid within an ARC chain.  Intermediaries MUST NOT create
>    any sets with any obsoleted algorithm.
> 
> 11.  Privacy Considerations
> 
>    The ARC chain provides a verifiable record of the handlers for a
>    message.  Anonymous remailers will probably not find this to match
>    their operating goals.

   to match -> compatible with

...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net