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 <barryle...@computer.org> 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 <ves...@tana.it> 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 <ves...@tana.it> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
