Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Scott Kitterman <[e-mail]>]

I think it's quite relevant.

The assumption that this is based on is there's a need to specify because SPF data is not reliable enough for everyone.  If that premise is correct (I don't agree with it, but it's a separate issue), then I think telling people that they should use DKIM because it IS reliable, when it's got its own issues isn't a great idea.

I've been mulling this whole topic over and I think I'm close to having mulled it enough to have a useful proposal.  SPF bad, DKIM good is a gross over-simplification, but so is if it passed SPF, it's authorized, so go whine at the provider.

Scott K

On June 28, 2023 6:32:41 PM UTC, Barry Leiba <[e-mail]> wrote:
>I think DKIM replay is largely irrelevant to this discussion (about
>the sender specifying which authentication to use), because if that's
>your biggest concern with respect to DMARC, then "SPF only" is the
>answer.  "SPF *and* DKIM" is not any better than that.
>
>> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply
>
>(Assuming you mean "replay".)  "SPF and DKIM" does not give any
>benefit beyond "SPF only" in this case.
>
>Look, either SPF fails because the message was relayed illegitimately...
>...or SPF passes because the replayer used the sender's legitimate
>infrastructure to do the replay.
>
>Barry
>
>On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely <[e-mail]> wrote:
>>
>> Thank you for your analysis.  However, it doesn't touch on DKIM replay.
>>
>> I know this topic belongs to the other list.  Let me briefly recall it, if this
>> doesn't take too many cycles from core matters:  It occurs when a signed
>> message is replayed by unauthorized hosts to recipients which were not
>> originally addressed.  So, it is one case of your 3rd proposition: In some
>> scenarios, DKIM will pass when SPF fails.
>>
>> You say that it is technically unnecessary to test both because DKIM should
>> always pass when SPF passes (1st proposition).
>>
>> You claim:
>> > But where the harm comes is in cases of mis-configuration, because now if
>> > *either* of them is misconfigured, the whole thing fails -- neither of them
>> > serves as a backup for the other; instead, the misconfiguration of either
>> > one causes deliverability problems.
>>
>>
>> I agree.  But what if SPF and DKIM are both configured properly?  You seem to
>> imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your
>> analysis doesn't cover that case explicitly.
>>
>> Perhaps there are better ways to counter that specific problem, and certainly
>> it's not what this WG is tasked to do.  But, just to make the point, I think
>> it's interesting to know.
>>
>>
>> Best
>> Ale
>>
>>
>> On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote:
>> > I don't understand how most of your message fits into this discussion:
>> > you're comparing SPF's policy points with DMARC policy.  we're talking
>> > about SPF as an authentication mechanism together with DKIM (not
>> > DMARC) as an authentication mechanism... and then using those
>> > authentication results in DMARC policy evaluation.
>> >
>> > But here: I've said all this before in separate places, so I'll put it
>> > in one place, here, one more time:
>> >
>> > Given that SPF and DKIM are both configured properly:
>> > 1. If SPF passes, DKIM will always pass.
>> > 2. If DKIM fails, SPF will always fail.
>> > 3. In some scenarios, DKIM will pass when SPF fails.
>> >
>> > Therefore, when everything is configured properly, SPF adds no value
>> > beyond what DKIM does, and DKIM does add value beyond what SPF does.
>> > That's why I am (and others are) arguing that we should remove SPF
>> > *from DMARC evaluation*.  There's no argument that for now, or some,
>> > SPF outside of DMARC still has value.
>> >
>> > What others are arguing is that in the real world, things do get
>> > mis-configured, and if DKIM is misconfigured and fails when it
>> > shouldn't, SPF adds value by providing a working authentication.
>> > (And, of course, similarly the other way around, plus DKIM covers some
>> > cases when messages are relayed or forwarded.)  That speaks for "SPF
>> > *or* DKIM".
>> >
>> > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
>> > unnecessary at best, because of (1) above: DKIM should always pass
>> > when SPF passes.  But where the harm comes is in cases of
>> > mis-configuration, because now if *either* of them is misconfigured,
>> > the whole thing fails -- neither of them serves as a backup for the
>> > other; instead, the misconfiguration of either one causes
>> > deliverability problems.  DMARC is damaged by requiring an
>> > authentication situation that is unnecessary when things are properly
>> > configured, and that is more fragile than what we've been using, more
>> > susceptible to configuration errors than we've seen before.
>> >
>> > And I'm afraid that people will use it preferentially, *thinking* that
>> > it provides better "security" -- surely, double authentication is
>> > better than single, no?
>> >
>> > No.
>> >
>> > Barry
>> >
>> > On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely <[e-mail]> wrote:
>> >>
>> >> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
>> >>> I'm saying I don't want "and" to be an option, because I think it's
>> >>> damaging to DMARC.  There is no reason anyone should ever want to say
>> >>> that, and providing the option asks for misconfigurations because
>> >>> people think it's somehow "more secure".  It's not more secure.  It
>> >>> would be very bad for deliverability of legitimate mail and would
>> >>> provide no additional security.  It would be a terrible mistake.
>> >>
>> >>
>> >> I've been sporting spf-all for years, and seldom experienced bounces, mostly
>> >> due to misconfigured secondary MXes.  Out of 39 domains whose posts to this
>> >> list in the past year are still in my inbox, 14 have spf-all.  So, while I'm
>> >> not the only one, not many published -all even though it may seem to be somehow
>> >> more secure.
>> >>
>> >> I think it can be worth to compare SPF and DMARC.  Another sender policy a
>> >> decade and an authentication method after.  What adoption, what hype.
>> >>
>> >> Both policies ask receivers to reject a domain identifier in some cases.  RFC
>> >> 7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC provides
>> >> for overrides but is less clear about how to handle exceptions.  After SPF
>> >> broke forwarding, the reaction was split between some changing identifier and
>> >> turning to ~all; after DMARC broke mailing lists, between changing identifier
>> >> and not altering messages.  In my limited experience, the ratio seems to be
>> >> higher for DMARC than SPF, but I may be wrong.
>> >>
>> >> In theory, domains that currently have a strict DMARC policy and spf-all, 6 of
>> >> the above, should have their messages blocked when either method fails, up to
>> >> changing identifiers.  Why would it be so bad for deliverability to
>> >> additionally require DMARC alignment, which is the difference between that and
>> >> the "and"?
>> >>
>> >> And, it seems to me that an ESP not having a bloated SPF record could stop a
>> >> good deal of DKIM replay by resorting to auth=dkim+spf.  Besides collateral
>> >> deliverability problems, why wouldn't that work?
>> >>
>> >> Wht would "and" damage DMARC more than -all damaged SPF?
>> >>
>> >> I hope we can discuss detailed criticism rather than vague ostracism.
>> >>
>> >>
>> >> Best
>> >> Ale
>> >> --
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> > _______________________________________________
>> > dmarc mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dmarc
>
>_______________________________________________
>dmarc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmarc