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

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 08:28:04 -0700

Folks,

I posted my review 2 weeks ago and haven't seen any responses.

 From some offlist exchanges, I think some believe the review responses 
are merely editorial.  They aren't.

While some of the review does point to (merely) editorial issues that 
are best resolved by the document editor, some others need to have wg 
discussion and develop wg consensus (IMO).

In case the length of the review has made it problematic for wg 
participants to identify such points, here's a listing of some items I 
think obviously need that discussion:

On 7/27/2017 6:19 PM, Dave Crocker wrote:
> 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.

The above two might seem only editorial but, really, they require more 
wg clarity about what the document is actually specifying, normatively.

> 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.

This is a basic goal question.

> 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.

This is a basic scope question.

> Detailed Comments:

> 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:".

I think this goes to the basic concerns that Bron has expressed.  That 
makes it a wg question, not editor task.

>>    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.

wg.

> 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.

Might be only an editorial issue, but given questions such as Bron has 
raised, I suspect there is a broader need to formulate wg clarity about it.

>>    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.

Could be merely editorial, but again, I suspect there is a lack of wg 
clarity.

>> 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.

wg, not just editorial.

>> 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?

wg.

>> 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.

This could be merely editorial, but, again, the example of Bron's 
concerns suggests that the remedy needs to be a wg process.

>>
>>    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.

Maybe editorial, but I suspect wg clarity is needed.

>>
>>        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:

ditto.

>>        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?

editorial?

> 
>>        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.

editorial?

> 
>>        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.

editorial?

> 
>>        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?

Basic enough to need wg clarity.

>> 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.

wg

> 
>     signing implementation -> signer
> 
> 
>>    The signing agent should undertake the following steps:
> 
>    should ->? SHOULD
> 
> but why not MUST?

wg.

> 
>>    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.)

Doc scope. Wg, not just editorial.

>>    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.

wg.

>> 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?

wg?

>>
>> 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.)

wg.

> 
>>
>> 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?

wg.

>> 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.

definitely wg.

>> 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.

wg!

>> 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...

wg.

> 
>> 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.)

wg.

>> 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?

wg

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Aug 2017 09:24:05 -0700

On Fri, Aug 11, 2017 at 8:28 AM, Dave Crocker <[email-masked]> wrote:

> From some offlist exchanges, I think some believe the review responses are
> merely editorial.  They aren't.

I did see your post, but have not yet had enough time to engage effectively
with it. I've also started working through the feedback from Alexsy but
jury duty this week and $dayjob responsibilities have slowed my progress on
that as well.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 09:29:18 -0700

On 8/11/2017 9:24 AM, Kurt Andersen (b) wrote:
> I did see your post, but have not yet had enough time to engage 
> effectively with it. I've also started working through the feedback from 
> Alexsy but jury duty this week and $dayjob responsibilities have slowed 
> my progress on that as well.

Such messed up priorities.  Tsk.

But ack and tnx.

But since my understanding is that you are doing primary editing, also 
note that, really, this morning's note was meant as a prod to others, 
not you...

d/