Subject: [dmarc-ietf] ARC draft issues/clarifications

From: Gene Shuman <[email-masked]>
Date: Wed, 11 Jan 2017 11:14:02 -0800

Hi All,

I'm currently working on a test suite for ARC, and have run into a few
areas in the draft that could use some clarification, mostly with regards
to section 5.2.1, which seems like it needs a non-trivial update.  I've run
into the following issues:

- 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?
- Similarly, can messages with completely duplicate ARC sets still be
considered valid?

One might expect that these gross violations of the protocol would cause
chain validation to fail regardless, however the language

5.2.1.  Handling Violations in the ARC Sets
>
> .......
>
> numbers), such header field set(s) MUST be ordered as follows when
>
> analyzing for *validity* or subsequent signing:
>
>
> seems to imply otherwise.

- 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, that dont form a complete set.  Is there any
reason we're not removing those as well?  That seems easier.
- Say we're computing AS(2), and are provided with AS(1), AS(1), AMS(1),
AAR(1), where we have duplicated i=1 Arc-Seals.  It's not entirely clear
where the duplicate AS(1) is ordered in the signing process.  The relative
ordering of the two AS(1)'s is specified in the draft, but is it the case
that within an arc set, all AS's are signed before all AMS's?  I would
assume that the ordering is as I've specified above, but that ordering vs
say AS(1), AMS(1), AAR(1), AS(1) isn't entirely clarified.

Aside from this family of issues, I've also come across a few other issues
that I could use a a bit of clarification on for my work on the test suite.

-  Arc-Seals are explicitly forbidden for inclusion in
Arc-Message-Signatures, but there is no mention of possibly including
previous Arc-Message-Signatures in newer signatures, despite the fact it's
fairly pointless.  Is this intentional?
- For both seal & message signatures computation, the spec explicitly
states that relaxed header canonicalization is to be used, but for makes no
comment about body canonicalization for AMS.  Is simple a valid option?  It
may be worth explicitly noting this.

Any thoughts/feedback/clarifications with respect to these issues would be
greatly appreciated.

Regards,
=Gene

---

From: "John Levine" <[email-masked]>
Date: 12 Jan 2017 21:34:03 -0000

>- Similarly, can messages with completely duplicate ARC sets still be

My advice is to fail them all, since that's the way to get the message
back to MTA authors to fix buggy ARC code.

Perhaps at some time in the future we will see consistent breakage due to
legacy non-ARC code that we can recognize as broken but legit, and we can
agree to do workarounds for them.  But at this point, all the ARC code is
new, all of it should work, and if it doesn't, the people who can fix it
are still around to make the fixes.

R's,
John

---

From: Paul Rock <[email-masked]>
Date: Thu, 12 Jan 2017 16:52:50 -0500

As an owner of some of that ARC code, I'm with John here - if I'm
broke/malformed, fail the message and tell me so I can try to fix it.

On Thu, Jan 12, 2017 at 4:34 PM, John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Jan 2017 16:31:26 -0800

On Thu, Jan 12, 2017 at 1:34 PM, John Levine <[email-masked]> wrote:

> [...]

+1.

-MSK