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

[Hector Santos <[e-mail]>]

Hi,

I agree with your comments.

My input.

Keep in mind, that ignorant (non-supportive) ARC nodes will continue 
to process all DKIM-signature(s) found, such as what I see with your 
message:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=none author.d=gmail.com signer.d=ietf.org;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=none author.d=gmail.com signer.d=ietf.org;
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com 
header.s=20161025 header.i=gmail.com;
  adsp=none author.d=gmail.com signer.d=gmail.com;

That should be the first consideration and understanding in the 
pre-ARC DKIM world, i.e. how things are done now.

The order of the DKIM-signatures is generaly important here since the 
typical scenario (with a list) is:

  1) Good 1st original Author Domain signature is submitted,
  2) 1st signature invalidated at middle ware (LIST),
  3) Good 2nd Signature (resign) for LIST distribution
  4) MDA see failed original AUTHOR ADSP/DMARC Policy.

Overall, the MDA has no explicit 3rd party trust/policy knowledge of 
LIST or signatures beyond the 1st Author Domain (now broken) 
signature.  That's the basic issue and 12+ years old DKIM Policy model 
protocol dilemma.

I suppose there could be more middle ware, nodes, etc during the 
transport, but the First and Final processing nodes should be the 
essential protocol consideration.  If there is an cv=fail at #2, does 
that mean the resigning at #3 is invalidated as well?  We never really 
cared what happens in between during the transport, but with ARC it 
appears to be a major consideration to better understand transport 
paths.  How ARC will turn all this around, it remains to be be seen. I 
wish to understand this complex protocol first before justifying the 
massive overhead and experimentation cost being asked of SMTP/Email 
developers.

Thanks

Hector Santos, CTO
Santronics Software, Inc.


On 8/20/2018 6:28 AM, Murray S. Kucherawy wrote:
> (back from vacation and catching up)
>
> On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> Right.
>
>     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.
>
>
> I see two possible workflows here:
>
> (1) Verifier (to use the DKIM term) detects "cv=fail" and stops,
> because there's nothing more to do.  But the Receiver now has no ARC
> information except a raw "cv=fail" to relay via A-R or whatever.  But
> this, as you point out, flies in the face of the notion of giving
> receivers details about the message.  The Receiver now has to
> implement ARC to get whatever details might be prudent from the message.
>
> (2) Verifier sees "cv=fail" but will still attempt to verify it and
> maybe extract other salient details to add to an A-R.
>
> When you say "you see cv=fail and stop", I think of the first thing,
> which is alarming layer mush, and is also ambiguous in that if the
> Verifier stops dead at seeing "cv=fail", it doesn't matter at all what
> content got sealed.
>
> So if you mean the second thing, part of my issue goes away.
>
>     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.
>
>
> I think we're talking about distinct failure modes.  I totally agree
> with you in the case where the chain has failed because content was
> altered.  But doesn't your assertion here presuppose an at least
> syntactically intact chain?  If the chain is damaged to the point
> where it cannot be deterministically interpreted, the sealer adding
> the "cv=fail" might add a seal that a downstream verifier cannot
> correctly interpret.
>
> I understand what you're after but I also understand the intent behind
> 5.1.2, which is to produce something unambiguous.  My problem with
> 5.1.2 as it stands is that a verifier now has to try verifying the
> "cv=fail" two ways (one with everything, one with just the last
> instance), and at least one of them has to work.  We've cornered
> ourselves here by rejecting "cv=invalid".
>
>     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.
>
>
> I disagree, as stated above; a mangled chain cannot be sealed in a way
> guaranteed to interoperate.
>
>     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.
>
>
> I've no objection to collecting superfluous trace information to
> support the experiment.  What I'm concerned about is the introduction
> of weird protocol artifacts or ambiguities that could get baked in and
> hard to remove later.
>
> -MSK
>