Kurt, I think terminating the chain with a cv=invalid is a good approach. The general idea being that if there is any seal found with cv=invalid then validation fails & we don't continue the chain. When a good intermediary finds an invalid chain, a seal is affixed(no need for AMS, or AAR), with the cv=invalid value. Im assuming we no longer require the a,b,d,s tags at this point, as they're irrelevant. Or do we even want to consider having a 4th type of header field(ARC-ChainInvalid?), possibly with identifying or failure information, just so were not modifying AS too much? Are there any security concerns with either of these approaches that need to addressed?
An open question then is what constitutes an invalid set. I would suggest that only the cases of duplicated or malformed/invalid i= values are invalid sets. Missing/incomplete sets fail, and mis-ordered sets are handled normally. +++1 wrt Scott's comment about 512 bit keys. We inherit this requirement from the DKIM spec, but imho it is not reasonable. If this is worth discussing, perhaps we should move it to another thread? Regards, =Gene On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman <skl...@kitterman.com> wrote: > On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote: > > On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy < > superu...@gmail.com> > > > > wrote: > > > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <ku...@drkurt.com> > wrote: > > >> The intent of section 5.2.1 was never to deal with pathological > cases. It > > >> was to deal with somewhat broken MTAs that do stupid things like > > >> reordering > > >> headers in alphabetical order or slightly broken implementations which > > >> might replicate headers. > > >> > > >> Duplication is arguably fine as long as the duplicate is identical to > the > > > > > > original, but I think once you have to go so far as to evaluate that, > the > > > chain has actually been directly affected, and it's fine to give up. > > > > Gene's suggestions (omitted from this due to top posting) about creating > a > > new "invalid" CV tag value seems like a reasonable response to a badly > > broken (structurally) ARC chain. Since we are _a priori_ only interested > in > > good chains I don't think that adding this creates any exploits for bad > > actors since a malicious intermediary can destroy/corrupt/etc an ARC > chain > > any which way. > > > > I'm more concerned about pathologies that could be introduced in the > quest > > to affix an ARC set with i=(previous + 1) when the "previous" value is > > malicious (not a number, too big a number, etc). In some sense, we almost > > need an "end of chain, don't waste your time any further" signal. > > I'm not on the ARC list, so I'll pile on this thread here... > > I understand the minimum key size in the draft is 512 bits. I'm not > planning > on releasing any software that supports key sizes less than 1024, so I > guarantee you interoperability problems for small keys. > > For those that may have forgotten, I'll pass on a reminder of how well 512 > bit > keys work even half a decade ago: > > https://www.wired.com/2012/10/dkim-vulnerability-widespread/ > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
