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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
