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

["Murray S. Kucherawy" <[e-mail]>]

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