Subject: Re: [dmarc-ietf] invalid ARC chains

From: Brandon Long <[email-masked]>
Date: Tue, 7 Feb 2017 16:22:43 -0800

On Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen <[email-masked]>
wrote:

> On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman <[email-masked]> wrote:
>
>> Extricating this discussion from the one about key sizes.  We left off
>> at discussing whether we should implement something like a cv=invalid
>> for arc chains that are no longer well defined.
>>
>> Brandon, I think you had the last response, and suggested that
>> receivers just refuse to continue to process invalid chains?  This
>> seems plausible, and might be simpler.  I have no strong opinions one
>> way or the other, although I think I slightly prefer the cv=invalid
>> state, as it strictly defines what receivers are to do with invalid
>> chains.
>>
>> Regardless, I still stand by the fact that section 5.2.1 needs to go &
>> that we should probably explicitly codify what constitutes an invalid
>> arc chain.
>>
>
> I don't think that 5.2.1 needs to be deleted, just significantly
> refactored (which I plan to do next weekend).
>
> I think that having a participating receiver mark an chain as "broken
> beyond repair" (aka = invalid) is a beneficial terminal state beyond which
> no other mediators should perform any further ARC machinations. It's
> certainly possible that a malicious mediator could essentially break every
> ARC chain that it sees, but that's no different than what can happen today
> and also is a situation that we are not trying to solve.
>

One challenge is how to specify that a chain is cv=invalid.  It implies
being able to sign an invalid chain.

Brandon

---

From: Jacob Rideout <[email-masked]>
Date: Wed, 8 Feb 2017 12:28:49 -0500

> being able to sign an invalid chain.

What is expected workflow in this case?

Say I'm alumni-forwarder.edu, and I receive a message with an ARC set (and
for the sake of this example, these are forgeries). After checking the
signitures, I consider the ARC set to be invalid. Section 6.4.2 suggests I
inform the sender of a message integrity failure. However, presume (given
no other abuse or spam signals) I want to forward all the mail receive on
and ARC failure alone is an insufficent reason to stop my forwarding.

How do I proceed? Stip the existing ARC set and start over with i=1 ?  Set
cv=fail?

A downstream receiver still might want to trust the
[ARC-]Authentication-Results
appended by alumni-forwarder.edu, but I think currently would be advised
against it in the case of cv=fail.

- Jacob

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 8 Feb 2017 10:59:28 -0800

On Wed, Feb 8, 2017 at 9:28 AM, Jacob Rideout <[email-masked]> wrote:

> Say I'm alumni-forwarder.edu, and I receive a message with an ARC set
> (and for the sake of this example, these are forgeries). After checking the
> A downstream receiver still might want to trust the [ARC-]Authentication-Results

This question is exactly what we are discussing. There is no one else to
define what "should" be done. What do *you* think should be done?

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Thu, 9 Feb 2017 15:37:09 -0800

I see three options at first glance.

1) An invalid chain can not be signed, therefore it is left intact and the
chain can not be continued.  Anyone receiving the chain should be able to
notice it's invalid as well.  We could add another value in 6.4.3 for the
local Authentication-Results header.

2) We define some mechanism to sign headers even if the chain is invalid,
thus allowing a chain to continue with a cv=invalid statement.

3) We specify that a forwarder should remove all of the arc-* headers
associated with invalid chains.

I think fully specifying all the invalid cases for #2 is going to be
challenging, and will be the source of errors in implementations, and I
don't think the end result is likely to be worth it.

I'm leary of removing the headers and therefore the information in #3.
Based on the final copy of the mail, one wouldn't be able to know that the
arc chain was removed or why.  I guess one could rename all of the headers
instead, ie arc-signature to invalid-arc-signature or something.

So, I'm leaning to #1 myself.

Brandon

On Wed, Feb 8, 2017 at 10:59 AM, Kurt Andersen <[email-masked]>
wrote:

>> inform the sender of a message integrity failure. However, presume
>> (given no other abuse or spam signals) I want to forward all the mail
>> receive on and ARC failure alone is an insufficent reason to stop my
>> forwarding.
>>
>> How do I proceed? Stip the existing ARC set and start over with i=1 ?
>> Set cv=fail?
>>