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

[Jan Dušátko <[e-mail]>]

Scott, Barry,
as far as I understand, SPF are historic technology, but still have a 
reason why to use it. In my opinion (and concerns), it is also necessary 
to be aware of the extension of the individual protection methods 
provided by senders (amount of domains). This is not a deep analysis. It 
is possible that the numbers given will not be accurate.
SPF        87%
DKIM    13%
DMARC 63%
ARC         5%
As technologies are deployed not in a technological continuity, but 
according to the needs of system owners, they are therefore set 
intersections. For this reason, relying only on the combination of 
DKIM+DMARC technology could be unfortunate.
In terms of provability, each DKIM signed email will be sent from the 
owner of the authorized servers. Ideally, therefore, it is not necessary 
to combine SPF and DKIM, only DKIM could be sufficient. However, the 
following situations are a problem. As a rule, DKIM+DMARC is not fully 
implemented, part of the domains are protected by DKIM, part by DKIM + 
SPF, part by SPF only.
- Only DKIM and DMARC are implemented, yet the SPAM distributor sends an 
email without the DKIM signature and without the key information.
- Only DKIM and DMARC are implemented, and a signed email is available. 
The SPAM distributor starts repeatedly sending the same email 
(equivalent to a DOS attack).
- Only DKIM and DMARC are implemented, and a signed email based on 
RSA+SHA1 is available. Because it is possible to find collisions for 
SHA1, and the digital signature is actually an "encrypted hash," it is 
possible to send counterfeit mail with a signature that looks genuine. 
The solution is to use explicitly h=sha2, but if not specified, it is 
also possible to "downgrade the signature" against another key on this 
domain supporting SHA1 (any SHA1-based signature will be used).

These attacks are the first that came to my mind. How we can mitigate 
that threat? According to owner authorization of IP addresses, they 
protect against a different kind of attack than the digital signature by 
using DKIM.

On the other hand, SPF can bring beside of advancing security particular 
security reduction. Simply because most of services are "shared in 
cloud" right now. Cloud service providers generally provide the extent 
to which virtual services can operate. It is not a question of who has 
or does not have the ability to use the service (in meaning that service 
are approved to send e-mails beside of domain). In this case, it is not 
a problem to create a system in the cloud technology that starts mimic 
and send junk mail instead of an authorized organization. The methods of 
correction are reactive, so it will take some time before such an attack 
is detected and mitigated. However, even a limitation of scope can be 
supported by DKIM, as it limits the space from which an attacker can 
operate.

The whole problem is a single one. What tools to provide the domain 
owner with to set up a policy to protect the reputation of its mail 
services. From this, another question arises:
- To what extent can domain service managers' knowledge be trusted?
- Is it possible to set up policy processing rules so that non-standard 
situations like missing signature can be handled, or allow the owner to 
define how signatures will be used?
- Is it possible to unambiguously describe the rules to avoid 
implementation errors?
- How will the problem of mail forwarders and mailing lists be addressed?

regards

Jan


Dne 28. 6. 2023 v 21:43 Scott Kitterman napsal(a):
> 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