Re: [dmarc-ietf] ARC vs reject

[Jim Fenton <[e-mail]>]

On 5 Dec 2020, at 18:22, John R Levine wrote:

>> If a domain publishes p=reject, they’re requesting particular 
>> handling of a message they originate. ARC modifies that, which is 
>> good for mailing lists and similar intermediaries, but depends on a 
>> list of trusted intermediaries that is not under the control of the 
>> originating domain. That increases the attack surface for DMARC 
>> considerably.
>
> Not if the recipients use ARC reasonably, e.g., only on mail from 
> hosts with a history of not sending botware, use it to see whether a 
> message was originally aligned.  Anyone who misuses ARC is going to 
> have worse spam leakage than anyone can fix for them.

“Use ARC reasonably” then seems to depend on whether the recipient 
has a good reputation system for evaluating the trustworthiness of 
message modifiers. There isn’t a good track record in creating and 
deploying such reputation systems, as you well know. In this case 
specifically, there is the question of what happens when a domain user 
subscribes to a mailing list, or has their mail forwarded with 
modification, from a new intermediary.

>> The question I have is: Should DMARC have a policy (or policy 
>> modifier) that says, “Do not accept modifications to this 
>> message?” In other words, that the originator values the integrity 
>> of their messages over deliverability.
>
> Of course not.  That's just the tiny gorillas stamping their teensy 
> feet. Why would anyone expect that the people publishing that flag 
> actually understood what it meant?  Many will just turn it on because 
> someone said it's "more secure."

FWIW, I don’t think a lot of the people publishing p=reject understood 
the implications of that, either. This is not significantly more arcane.

> A lot of this boils down to what if some entity sends signed valid 
> DMARC aligned mail but somehow doesn't mean it, e.g., an internal 
> policy says no mailing lists but their users participate in lists 
> anyway.  If they can't control their own mail system, it is not anyone 
> else's job to do it for them.

It isn’t a question of controlling their own mail system. One of the 
value propositions of DMARC is effectiveness against phishing. Suppose a 
phishing attacker composed a message purporting to be from someone the 
victim trusts (including a DKIM signature that doesn’t verify because 
the message has supposedly been modified), and then makes it look like 
it has been forwarded by a throw-away intermediary they control and adds 
valid ARC header fields signed by the supposed intermediary. If the 
recipient domain accepts modifications by zero-reputation intermediaries 
(because there are so many of them, after all), DMARC policy is ignored 
and the message is delivered normally. The premise of DMARC is that the 
originating domain has an interest in expressing how messages purporting 
to come from their domain should be handled, and this attack uses ARC to 
override that.

I’d be interested in other opinions on this. Or whether this is a 
fundamental problem with ARC.

-Jim