Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

[Seth Blank <[e-mail]>]

On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker <[e-mail]> wrote:

> If there is a clear and compelling counter-argument of clear benefit that
> can be achieved, will be achieved, and is desired by receivers, what is it?


There are THREE consumers of ARC data (forgive me for the names, they're
less specific than I'd like):

1) The ARC Validator. When the Validator sees a cv=fail, processing stops,
the chain is dead, and shall never be less dead. What is Sealed is
irrelevant.

2) The Receiver. An initial design decision inherent in the protocol is
that excess trace information will be collected, as it's unclear what will
actually be useful to receivers. 11.3.3 calls this out in detail. Without
Sealing the entire chain when attaching a cv=fail verdict, none of the
trace information is authenticatable to a receiver (see earlier message in
this thread as to why), which is the exact opposite of the design decision
the entire protocol is built on. To guarantee this trace information can be
authenticated, the Seal that contains cv=fail must include the entire chain
in its scope. This is where this thread started.

3) The receiver of reports that provide ARC data. For a domain owner to get
a report with ARC information in it, there needs to be some level of trust
in the information reported back. When a Chain passes, all the
intermediaries' header field signatures can be authenticated, and the
mailflow can be cleanly reported back. When a Chain fails, that is
important information to a domain owner (where is my mailflow failing me,
how can I figure this out so I can fix it?). Again, without Sealing over
the entire Chain when a failure is detected, this information is
unauthenticatable (and worse, totally forgeable now without even needing a
valid Chain to replay), and nothing of substance can be reported back.
Sealing the Chain when a cv=fail is determined blocks forgery as a vector
to report bogus information, and allows authenticatable information to be
reported back.

So to recap: Yes, when you hit cv=fail the chain is dead and shall never be
less dead. But to preserve trace information as was the initial design
decision, and make sure report data is meaningful and cannot be forged,
when a cv=fail verdict is attached the Seal must cover the entire chain in
its scope.

And to be even clearer: what is Sealed when cv=fail is reached (itself, the
entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But it
does effect preserving trace information and preventing forged data from
being reportable.

This is my very strong INDIVIDUAL opinion. But I'm fine if the group sees
differently, as this could be investigated as part of the experiment (i.e.
do any of the above points matter in the real world? I say they do, hence
the strong opinion.). As an editor, I'll make sure whatever the consensus
of the group is is reflected in the document.