On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman <[email protected]> wrote:
> I think its clear that we fail all of these messages. But for signing, we > need to specify an ordering on these pathological arc headers, as section > [5.2.1] only applies when you can logically define arc sets. We also > probably need this ordering to downgrade to that in section [5.2.1] when > applicable, and to the defacto ordering in the standard case. > > The obvious solution here is to simply sign *all *arc headers under all > sealing/validation operations in a bottom up order, regardless of the > validity/ordering of the headers in the email. Reasons that this is good: > - This is the simplest language > - This probably has the simplest implementations > - Assuming validly signed inputs this defaults to the ordering in section > [5.1.1.3] > - This also defaults to section [5.2.1], in the slightly less valid, but > still broken state, apart from the alphabetical ordering clause > - I think this is basically what's implicitly intended throughout the > draft. > > The only other way I can see to approach this issue is to continue down > the path of [5.2.1] and define an additional ordering on these pathological > cases. It seems wrong to me to force implementors to provide whatever > weird sorting functionality this would be, just for the sake of signing > pathological examples, so I recommend against this approach. > > So I think the universal bottom up ordering is the way to go. Anybody > have any opinions here? I'm happy to take the lead on proposing changes to > the draft. > This is also what I had in mind. If I receive a bunch of ARC Sets that are not all pristine at least in terms of being complete (exactly one of each of the ARC header fields) and/or there are gaps in the instance sequence, then the chain is de facto invalid and I should report it as such using "cv=fail" when generating my own seal. I suggest we don't even attempt the crypto operations to verify any of the existing seals or AMS fields. There's some history of being gentle or forgiving in the email space, and it has never served us well. (See RFC7103, for example.) We shouldn't subject ARC to such vagueries, especially when people are betting on it solving a lot of problems. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
