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 protected]> Date: Wed, Jan 11, 2017 at 12:50 AM To: [email protected] 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 protected]> Date: Wed, Jan 11, 2017 at 12:57 AM To: Gene Shuman <[email protected]> Cc: ARC Discussion <[email protected]> On Tue, Jan 10, 2017 at 11:20 AM, Gene Shuman via arc-discuss < [email protected]> 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 protected]> Date: Wed, Jan 11, 2017 at 1:03 AM To: "Murray S. Kucherawy" <[email protected]> Cc: ARC Discussion <[email protected]> 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 protected]> Date: Wed, Jan 11, 2017 at 5:57 AM To: Gene Shuman <[email protected]> Cc: ARC Discussion <[email protected]> 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 protected]> Date: Wed, Jan 11, 2017 at 7:13 AM To: "Murray S. Kucherawy" <[email protected]> Cc: ARC Discussion <[email protected]> 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 protected]> Date: Fri, Jan 13, 2017 at 3:00 AM To: [email protected] In article <CAL0qLwZa45bxp=oztB-MYPPayZGVTmqSvSdCG_gpZNo6y+ [email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
