On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote: > On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy <[email protected]> > > wrote: > > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
