On Tue, Jul 17, 2018 at 4:59 PM, Dave Crocker <dcroc...@gmail.com> wrote:
> Review of: draft-ietf-dmarc-arc-protocol-16 (partial)
> Date: 17 Jul 18
> Reviewed by: D. Crocker
>
>
> Summary:
>
> I gave a review for -14 and will skip the pro forma functional summary.
>
> I reviewed the initial portions of the -16 draft and see some basic and
> pervasive language problems that are serious enough to make it likely that
> a reader will misunderstand core ARC concepts. I've suggested alternative
> language, where I could.
>
> d/
>
Thanks for this, and keep them coming.
Your review of -14 was heavily folded into the rewrite of -15, but I don't
believe anyone ever said this on list. That was an oversight.
> My review of -14 noted problems with the abstract. While there have been
> some changes, the Abstract remains too... abstract. While the current text
> is better it really does not provide simple, direct statements about the
> problem(s) ARC is addressing nor the solution or benefit that it enables.
>
> Text like this needs to be written for people who are not trained in
> theoretical computer science and are not already deeply enmeshed in this
> work.
>
The abstract's been rewritten numerous times, including with the help of
the Chairs and AD. I do like your suggestion, but would appreciate hearing
if other members of the working group concur with your guidance.
> Note also that while typical discussion of ARC refers to it as
> establishing a chain of custody, no language like that is in the Abstract.
> I think that's a serious omission.
>
This is a fair point, but I think discussing custody in the abstract has
led us down less clear paths previously. Raising these issues in a General
Concepts section seems to have clarified and simplified the document.
editorial, to simplify and reduce redundancies, replace the above paragraph:
>
> DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So their
> failures that are caused by the actions of intermediate handlers can in
> turn cause legitimate mail to be incorrectly rejected or misdirected.
>
> (drop the 'all aspects' sentence.)
>
That works.
> I think this means based on 'legal' concepts of evidence, really. While
>> it theoretically should apply to all handling of anything one might call
>> evidence, this really is drawing from the legal world, isn't it?
>
>
The original text here referenced legal concepts, but it didn't add
anything valuable and was stricken for the sake of simplicity and clarity.
> A term like "authentication state" needs to be defined or at least
> explained, given its importance to the text here.
>
Agreed.
> There's an argument one can make that the term is actually inappropriate.
> I don't think this activity has a concept of an authentication state
> machine. One might invent such a thing and might even be useful, but it
> hasn't been done, has it?
>
> While it's not as verbally tight, I suspect language more like "validation
> of message authentication information" or "authentication assessment" or
> "authentication validity" are both more intuitive and correct.
>
> (BTW, this might be why 'evidence' is a problematic term, since, really,
> assertions about prior validations constitute a kind of hear-say; it's
> second-hand information, not direct, objective 'evidence'. Though it might
> be a bit facile, an alternative choice could be 'testimony'...)
>
Also agreed. We'll review and suggest language; I'm leaning towards
"authentication assessment."
Custody refers to when any Internet Mail handler processes a message.
>>
>
> (Applicability of the term does not depend on ARC, or at least it
> shouldn't.)
>
> ARC provides a means of /authenticating/ custody.
>
The General Concept Terms exist to provide a framework for those unfamiliar
with ARC to understand it. While you are correct that any handler has
Custody irrespective of ARC, while setting up the framework for those new
to ARC we're only specifically talking about the ARC representation of
custody. Removing the reference to ARC makes this less clear to a new
reader.
You are correct that ARC provides a means of authenticating custody of a
message; we will look at folding this language into section 2.4, I believe
it is more clear than the current text.
> *** MAJOR ***
>
> ARC does /not/ allow verifying the authenticity of earlier 'evidence',
> other than the evidence of handling signatures. That is, assertions about
> prior validations are not really 'evidence'.
>
> This is a persistent point of confusion about ARC and I consider it
> serious.
>
> Using ARC requires developing trust in the handlers that make these ARC
> assertions of earlier validity. This is quite different from a later
> handler 'verifying' that validity, since it can't.
>
> *** ***
>
I concur with your final thought, but am unaware of this being a point of
confusion. This is explicitly called out in Security Considerations 9.4.
> No, it can validate who made what assertions -- and in what order -- not
> that the assertions were valid.
>
Yes. That was the intent of this language, we'll clarify.
> evidence-supplying Custodians can be trusted, then the validated
>> Chain of Custody describes the (possibly changing) authentication
>> state as the message traveled through various Custodians.
>>
>
> It can validate statements about authentication, not the actual
> state/correctness of those statements.
>
Correct. I believe this clarifies itself when we change "authentication
state" to "authentication assessment" and have that properly defined
earlier in the document.
> The term 'intermediaries' does not appear in 5598. Nor does a term like
> 'intermediate handler'. Worse, the document here probably needs a term
> that covers both regular MTAs AND delivery/re-posting agents such as
> mailing lists, which is what RFC 5598 calls 'mediators'.
>
This is why "Internet Mail Handler" was defined in section 3. However, its
prominence appears lost due to formatting. We'll fix that.
> fields -> fields that are added to a message by an ARC transit system.
>
>
> (That is, an arc set is a specific instance, not the abstraction that
> defines those 3 fields.)
>
Fixed.
> "The complete sequence"
>
> Hmmm... /What/ complete sequence? Do you mean the complete sequence
> attached to a message at any one point during transit? Or do you mean the
> complete sequence attached to the message after final delivery? Or...?
>
> (On reflection, I suggest calling a sequence under development -- that is,
> one being built during transit -- a 'partial sequence' and save 'complete
> sequence' to refer to what exists after final delivery.)
>
I think this is clarified by simply stating "the complete sequence of ARC
Sets attached to the message at any given time"
> Might be worth explaining why the term 'signer' isn't sufficient for this,
> since a reader will likely think it the more natural choice.
>
This is why 5.1.6 exists; in general concepts this nuance is confusing.
Over the years, I've come to believe that good ABNF formatting aids readers
> quite a bit. So I suggest something like:
>
> position = 1*2DIGIT ; 1 - 50
> instance = [CFWS] %s"i" [CFWS] "="
> [CFWS] position [CFWS] ";"
> chain-status = ("none" / "fail" / "pass")
> seal-cv-tag = %s"cv" [CFWS] "="
> [CFWS] chain-status
Yes, there are several formatting issues that need to be fixed in the final
XML.
Thanks,
Seth
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
