Subject: Re: [dmarc-ietf] ARC cv=invalid

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jul 2017 15:24:07 -0700

On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long <[email-masked]> wrote:

> On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) <[email-masked]>
> wrote:
>
>> On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman <[email-masked]>
>> wrote:
>>
>>>
>>> It seems we have two choices available to us upon receipt of an invalid
>>> chain(which is defined as AS b= unable to be computed).
>>>
>>> 1. Simply stop adding further ARC headers.  Put arc=fail(or invalid) in
>>> the AR.  Further recipients will detect that the chain is broken as well,
>>> for the same reasons.  This is clearly the easiest solution.
>>>
>>
>> If you put arc=fail in an AR and then the next hop ignores and strips the
>> AR (per spec), what good is it?
>>
>
> None, but what good is the broken chain?  If all you're doing is avoiding
> reprocessing, that seems pretty minimal.
>

A message that doesn't have a chain that ends with "cv=fail" or
"cv=invalid" has undetermined status.  You (the receiver) now have to
evaluate the chain.  Why make everyone downstream of you go through that if
you know it's bad?

Of course, there's no reason they believe you if you say it's bad, but then
what benefit do you have to lie?

>
>
>> 2. Add one further ARC-Set with an explicit cv=invalid in order to
>>> 'close' the chain, using the rule that Kurt has suggested.  This seems to
>>> have some benefit to me, but it's minimal.  It seems to wrap things up
>>> nicely, and it means that all ARC chains have a well defined cv value,
>>> which makes testing a little easier.  However the cost is clearly added
>>> complexity, both in the spec and implementations.  Is there any other
>>> tangible value to adding this final ARC-Set?  Does it help identify the
>>> failure point in the chain?  Is there any other benefit?  Kurt, can you
>>> speak to this?
>>>
>>
>> A terminal ARC-set with cv=invalid is the only way to "close" a chain and
>> avoid reprocessing by each and every subsequent hop as far as I can see.
>>
>
> Note that we don't have a temp fail, so cv=fail could just be due to DNS
> being unavailable, so the next hop may actually be able to validate the
> chain, assuming the failing hop was a non-modifying hop.
>

Should "cv=" have a way to indicate "pass up to here, but the hop that
added this seal didn't/couldn't actually evaluate anything"?

Maybe more importantly: Should the spec accommodate an operator that
chooses to pass a message along with some chain status that isn't "pass" or
"fail"?  I would think that's a hole of some kind.  Maybe we need to say
you need to queue the message or tempfail it back out the front if you
can't complete the evaluation.

Would you expect the next hop to also had a cv=fail arc header that only
> signs itself?
>
> I'm just fundamentally unclear what the utility of passing the fail state
> forward is.
>

I suggested above that it tells the new receiver that this chain is
probably not going to pass, so don't bother.  There's no benefit to saying
that when it's not true, or not saying it when it is.

> That said, there are plenty of cv=fail which have nothing to do with the
> chain structure, and could be dns or ams signature failures or whatever.
>

AR allows for a status that means "this couldn't be evaluated right now,
and we decided to pass it along anyway".  But DKIM signature evaluation is
stateless from one hop to the next, so it's fine for DKIM.  It's
not-so-fine for ARC.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jul 2017 15:25:18 -0700

On Wed, Jun 21, 2017 at 6:19 PM, Seth Blank <[email-masked]> wrote:

> A final evaluation status has merit, but it's not avoiding reprocessing,
> it's transmitting and signing your name to a definitive position that the
> chain is dead as you saw it.
>
> An ARC chain is a chain of custody, and if custody is lost, that status
> shouldn't be a hot potato - it should be committed to the chain. And then
> per the logic in the spec, no one else touches the chain after the chain is
> declared dead.
>

I think I agree here.  The absence of a "cap" on the end of the chain is
ambiguous, while a signed "cv=fail" is not.

-MSK