> O365 may also have a ton, but again, probably whitelistable as a single entity
We’re trying to get this signed by groups.office.net. -- Terry From: dmarc [mailto:[email protected]] On Behalf Of Brandon Long Sent: Tuesday, August 23, 2016 5:20 PM To: Alessandro Vesely Cc: dmarc-ietf Subject: Re: [dmarc-ietf] ARC and weak signatures (again) On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely <[email protected]<mailto:[email protected]>> wrote: On Tue 23/Aug/2016 02:07:24 +0200 Brandon Long wrote: On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely <[email protected]<mailto:[email protected]>> wrote: Say A -> B -> C are the MTAs: C sees a message where B is cited in the To: or Cc: header fields. The message is ARC signed by B. B says A's DKIM signature was good, but now it is broken. A's DMARC policy says that C should reject in that case. What should C do? If C is gmail, it likely has sufficient history to know how A and B behave. But what about small MTAs whose email flow is statistically not enough to use combinatorial trust assessments? If your MTA is too small to use combinatorial trust assessments, then you are stuck with the same two options you have today: manual whitelists or using a service to give you that information. If you're small enough, I don't think manually whitelisting the mailing list servers your users are subscribed to would be that challenging, especially if you receive the DMARC reports your server generates. I can configure my filter to accept DMARC-failed messages from authenticated domains which are trusted MLMs. Even if I only see 20~30 new mail domains each day, I'm not going to manually look for names which seem to be lists. A two-step heuristic to determine trusted MLMs consists of (1) collect domain names from received List-Post: header fields matching <mailto:*@*.*>, and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains collected that way, select those that my users write to. _Small domains_ --by definition, for the scope of this discussion-- have no anonymous users. That heuristics keeps failing until a subscribed user actually posts to a MLM. Skipping step (2) makes it an obvious attack path, but whitelisting can mitigate it a bit. How can aggregate reports help here? Would you please expand? aggregate reports you send to others would tell you about posts you were rejecting. And I guess it depends on what "small" means, if you're seeing 20-30 new domains a day that are lists and you're rejecting for DMARC, then yes, that may be beyond the ability to whitelist. If you were actually seeing 20-30 whiitelistable mailing list domains a day, I think you might get >90% of them in a couple months. Ok, that's not true, Google Apps allows domains to have mailing lists, but that's probably the bulk of them... but they'll all be ARC signed by the same provider (google.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgoogle.com&data=02%7c01%7ctzink%40exchange.microsoft.com%7c723de85caec64ffeb2d708d3cbb458a1%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636075947847055377&sdata=XnSxn8I2o6IQ4YGCuf55UmtKUKtaAbVGuHR%2bCirvMhs%3d>). O365 may also have a ton, but again, probably whitelistable as a single entity. If A had added a second DKIM signature, signing just the To: or Cc: field(s) which cited B, with l=0 for the body, then that signature likely survived B's fixing and hence C could infer that B is a true (not self-styled) forwarder. IOW, A's second (weak) signature provides C with a formal criterion to instruct its local policy to accept email that fails the DMARC mechanism check even if A has published a "reject" policy. So, what I called ARC-0 in my former proposal, doesn't really have much to do with ARC. The concept is weak signatures. Of course, they won't work unless carefully standardized and implemented. The question is if they will ever work at all, and if this WG is willing to consider them. If not, we need to address Dave's concern some other way, or resign ourselves to building a solution which will likely work 98.7% for some and 0.2% for others. So, any message sent from A to B can then be used as a replay with any content to any party as long as the To/Cc are intact? That seems pretty useless. Yes, B can send whatever they like using your name@A. That's how weak signatures work. Of course, valuable domains such as banks and other phish targets should never use them. Our task here is to better indirect flows, not counter phishing. Anyway, regular domains may want to weak-sign only the copy of a message addressed to a trusted MLM. Bumping DKIM version was proposed as a means to have C also require a valid signature of B. Some receivers already use local policies to limit the shape of DKIM-Signatures they accept; for example, some regard signatures with l=0 as invalid. Smart C-role verifiers may want to match B to To: or Cc: before accepting weak signatures. I'd put weak signatures when I play A. That way I'd complement the above technique, trusted MLMs whitelisting, which I'd use when I play C. An additional element would be to have B save From:. In fact, A's weak h= should not include From:, because rewriting From: currently seems to be the best anti-DMARC workaround. B would save the value of From: using a new header field name, e.g., say, Original-From:, Authenticated-From:, or ARC-From: for daisy chaining (vote for one). Finally, C may consider the presence of this new field to confirm A's role, and possibly fix From:. In those cases, a message passes if C is either smart or dumb, not somewhere in between. DKIM v=2 would eliminate the "dumb" side. But you're still whitelisting MLMs in C, or even possibly in A in this scenario. If I were clever, I would list all possible statuses of A, B, and C (such as complying with DKIM, DMARC and ARC, applying or recognizing weak signatures, being aware of either DKIM v=2 or the new header field, et cetera) along with the relative probabilities that they are implemented at various stages in time, and then compute the chances that C can pass/reject correctly in the two cases of B being white or black, at each stage. I reckon there are cases of A unknown to C, perhaps because either is small, where some mixes of the above techniques would save the day, thereby encouraging more small domains to publish strict DMARC policies, don't you think? I'm not sure if that's a goal. Brandon Ale --
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
