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]> 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?
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.
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?
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
