Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

[Terry Zink <[e-mail]>]

> The fact that a proposed change doesn't receive favourable response 
> doesn't mean it didn't get considered, does it?

While I don't really agree with the reasons for the unfavorable response, I do acknowledge that this proposal has met with strong resistance. There's probably a better way to solve this. For example, if an organization behind a cloud-based service wants to prevent spoofing, it could say "The domain example.com always DKIM signs its mail" and then any unsigned mail would be rejected (or rerouted). This is a private ADSP.


> If in Terry's application "require both" is an acceptable outcome, 
> then his customer base was either prepared to delegate DKIM or do it 
> themselves anyway.

I did use myself and the company I work for as an example, but the scenario extends to many cloud-based providers of email.

A better forum may be a working-group session at MAAWG, or a set of Best-Practices. 

-- Terry


From: [e-mail] [mailto:[e-mail]] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 01, 2013 10:50 PM
To: J. Gomez
Cc: [e-mail]
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

On Mon, Apr 1, 2013 at 7:44 PM, J. Gomez <[e-mail]> wrote:

So, you want the public to aknowledge a private practice as a public standard, and at the same time you don't want input from the public but blind adhesion, because, you know, it has been working fine in our private club?

In contrast, you're expecting that any suggestion made in this more public venue automatically has to be accepted?  But either way we're getting ahead of ourselves; there isn't even a working group yet.

As has already been pointed out, DMARC hasn't been private for quite some time.  The point here is indeed to subject the specification to even more open and rigorous review that it's already received.  There's been a public (albeit external to the IETF) mailing list for a long while now.  The fact that a proposed change doesn't receive favourable response doesn't mean it didn't get considered, does it?
As for actual technical arguments, I find John's and Scott's points compelling.  Neither DKIM nor SPF are useful defenses if you can't control the content they authorize or authenticate.  In effect, in the attack scenario Terry provided, SPF is giving what the victim domain perceives as false positives.  Sticking with that scenario, the solution appears to be to remove SPF from the equation by neutralizing its "pass" response when coming from those IP addresses.  I keep coming back to a Venn Diagram showing SPF pass and DKIM pass plus their overlap, which is the DMARC pass space; if you don't want DMARC to pass for the case where SPF passed but DKIM failed, then DMARC pass is now logically equivalent to DKIM pass.  To enact that, just turn off SPF and sign all your mail.

On the flipside, if the victim domain's signing keys were compromised, one could generate spam signed as them from any IP address, rendering DKIM meaningless but SPF effective (probably).

I don't find the argument that delegating DKIM is hard to be believable.  If in Terry's application "require both" is an acceptable outcome, then his customer base was either prepared to delegate DKIM or do it themselves anyway.
Where is the danger? You don't have the need?, well then go with the more relaxed default.

I don't believe anyone's calling the proposal "dangerous", but the reasons for the resistance have already been laid out.
 

> I use shared IPs across domains
> but I DKIM sign those domains and each of the domains has similar
> security implementations. So from my perspective it is possible to
> do.... I've been doing it for years.
So what? Good for you. The world is wide. One size does not fit all, yada yada...

That doesn't mean this is the right place for all solutions to all configurations, does it?
 

Again, is the proposed optional extension damaging to DMARC's goals? Are DMARC's goals those of a private club, or those of the non-spoofing email community at large?

The latter, but don't conflate that goal with a requirement to be all-inclusive either.  We couldn't alter DKIM to make it work seamlessly with all mailing list configurations, so we stopped trying.  That doesn't mean DKIM had a private set of requirements; rather, it had realistic ones.

-MSK