Subject: [dmarc-ietf] Fwd: [arc-discuss] a few questions about the spec

From: Kurt Andersen <[email-masked]>
Date: Mon, 16 Jan 2017 16:51:36 +0530

Per the excellent eyes of Steven Jones, this conversation was happening in
a less-than-optimal forum. I'm forwarding the whole chain to the dmarc WG
so that it can continue there instead.

--Kurt

Forwarded conversation
Subject: [arc-discuss] a few questions about the spec
------------------------

From: Gene Shuman via arc-discuss <[email-masked]>
Date: Wed, Jan 11, 2017 at 12:50 AM
To: [email-masked]

Hi All,

I have a few fairly straightforward questions about the current spec I'm
wondering if somebody can help me out with:

- Can messages with violations in their ARC sets(duplicate/malformed i=
values, etc), still be considered valid, assuming they pass the chain
validation algorithm under the given ordering?  I think the language
implies so, although its a bit unclear.

- Similarly, can messages with completely duplicate ARC sets still be
considered valid?

- Can we include previous Arc-Message-Signatures in newer message signature
hashes?  Only Arc-Seals are expressly forbidden?

----------
From: Murray S. Kucherawy via arc-discuss <[email-masked]>
Date: Wed, Jan 11, 2017 at 12:57 AM
To: Gene Shuman <[email-masked]>
Cc: ARC Discussion <[email-masked]>

On Tue, Jan 10, 2017 at 11:20 AM, Gene Shuman via arc-discuss <
[email-masked]> wrote:

> - Can messages with violations in their ARC sets(duplicate/malformed i=
> values, etc), still be considered valid, assuming they pass the chain
> validation algorithm under the given ordering?  I think the language
> implies so, although its a bit unclear.
>
> - Similarly, can messages with completely duplicate ARC sets still be
> considered valid?
>

I would consider both of these to be errors.

> - Can we include previous Arc-Message-Signatures in newer message
> signature hashes?  Only Arc-Seals are expressly forbidden?
>

I think not, in the same way that DKIM-Signatures don't sign other
DKIM-Signatures.

-MSK

----------
From: Gene Shuman via arc-discuss <[email-masked]>
Date: Wed, Jan 11, 2017 at 1:03 AM
To: "Murray S. Kucherawy" <[email-masked]>
Cc: ARC Discussion <[email-masked]>

I would expect the first two cases to be errors as well, however the spec
somewhat unclearly implies otherwise:

5.2.1.  Handling Violations in the ARC Sets
>
> When ordering the ARC header field sets, if there are gross
>
> violations of this protocol (e.g., such as duplicated instance
>
> numbers), such header field set(s) MUST be ordered as follows when
>
> analyzing for *validity* or subsequent signing:
>
>
I would also expect people not to sign message signatures, however I don't
think it's explicitly forbidden anywhere.

----------
From: Murray S. Kucherawy via arc-discuss <[email-masked]>
Date: Wed, Jan 11, 2017 at 5:57 AM
To: Gene Shuman <[email-masked]>
Cc: ARC Discussion <[email-masked]>

I agree, that section needs work.  To me it's a contradiction to provide a
workaround to something that constitutes a "violation" or a "gross
violation".  At that point the validation chain should be considered
broken, and that's that.

Others: Is there some reason we're doing contortions in these cases to get
such messages to validate?  I'm not sure the paragraph at the end of 5.2.1
provides enough value to offset the additional complexity.

-MSK

----------
From: Gene Shuman via arc-discuss <[email-masked]>
Date: Wed, Jan 11, 2017 at 7:13 AM
To: "Murray S. Kucherawy" <[email-masked]>
Cc: ARC Discussion <[email-masked]>

It would make sense that a gross violation would imply cv=fail, and that
the ordering shouldn't provide a workaround.  I do understand that their
still needs to a consistient way of generating signatures for broken
messages however.  Thinking a bit more about this raises a few more
questions about pathological cases:

- when implementing the ordering in [5.2.1] for signing, do we include ARC
header fields with invalid or non-existent values of i=?  missing, i=;,
i=-1;, i=string; are all cases that need to be addressed.  Easiest would be
just to not include them.
- Section [5.2.1] says to remove fully duplicate sets, but doesn't mention
fully duplicate instances.  In the case that we're computing, say AS(2),
and are provided with AS(1), AS(1), AMS(1), AAR(1), where the first two
AS(1)'s are identical, are both included in the AS(2) signature
calculation?  If so, in the order I've specified, or is the order something
like AS(1), AMS(1), AAR(1), AS(1).  This is unclear.  Is the case that
within an arc set, all AS's come before all AMS's, etc?

In general though, I think this section could use a non trivial update to
language.  If we can solidify the clarifications, I'd be happy to suggest
some changes.

Regards,
=Gene

----------
Suggestion from S. Jones to move to dmarc-wg elided here.
----------
From: John Levine via arc-discuss <[email-masked]>
Date: Fri, Jan 13, 2017 at 3:00 AM
To: [email-masked]

In article <CAL0qLwZa45bxp=oztB-MYPPayZGVTmqSvSdCG_gpZNo6y+
[email-masked]> you write:

>Others: Is there some reason we're doing contortions in these cases to get
>such messages to validate?  I'm not sure the paragraph at the end of 5.2.1
>provides enough value to offset the additional complexity.

The usual advice in the standards world is to tell people how to
interoperate, and if you want to interoperate, you follow the rules.

There are certainly places where we have workarounds for backward
compatibility.  But ARC is new.  There's no existing broken
implementations to compatible with.  My advice would be to strip out
5.2.1.  If an MTA is putting on broken ARC headers, the solution is to
tell the MTA authors to fix it.

R's,
John