Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
It appears that Barry Leiba said: >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. What he said. The group that invented DMARC thought about using both and specifically rejected it. I see no reason to believe they were wrong. (If someone's going to say that using both fixes DKIM replay, it really doesn't and it still has all the other problems.) It's still not clear how we would know whether anyone was paying attention to the "SPF only" flag, but since I don't think it's useful, I'm not worrying about it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
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. Barry On Mon, Jun 26, 2023 at 11:55 AM Murray S. Kucherawy wrote: > > Just to clarify something: > > On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba wrote: >> >> I can accept some mechanism for the sender to say "SPF only", "DKIM >> only", or "either SPF or DKIM". I cannot except a version of DMARC >> where *both* must pass. > > > I think the proposal before us is to allow the domain owner to indicate it > wants specific combination(s) of SPF and DKIM to pass in order for DMARC to > pass. I imagine the default would be "or" which is backward compatible with > what we have today, as the charter demands. > > Are you saying you don't even want "and" to be an option if it is made > configurable? Or do you just not want the "or" to change to "and" without > the proposed new tag? > > -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
DKIM+SPF says "our domain, including subdomains covered by this policy, will never use an ESP". (Since most ESP messages pass SPF based on the ESP domain) This seems unlikely to be a reliable assertion, so the effect on disposition is likely to be strongly negative, even without the effect on forwarders. I oppose. Similarly, SPF only seems unlikely to provide improved dispositions. Evaluators are unlikely to find it worth honoring. All I think we need is a tag that says,nl "ignore SPF if you understand DMARC" . Since only DMARC-aware evaluators will be looking for the policy which contains the tag, I see no obstacles. On Mon, Jun 26, 2023, 12:14 PM Alessandro Vesely wrote: > On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote: > > If we consider this sort of thing, I want to push to keep one thing > > off the table: > > > > Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach. > > Let's please just remove that from consideration. It has not been in > > DMARC up to this point, and it would be really bad to add it. > > Deliverability would be worse than ever because we would get the worst > > of both: fragility of SPF when messages are relayed/forwarded, *and* > > problems caused by misconfigurations in *either* SPF *or* DKIM. > > > I agree it'd be an extreme setting. It could only make sense in very > extreme > cases. However, in those cases it might make sense. > > In addition, if ARC-driven forwarding setups will gain the ability to > override > DMARC, at least for established forwarding paths, the forwarding > prohibition > would then be softened. After all, spf-all requires a comparable behavior > (except that SPF allows intermediate results) and many domains use it > satisfactorily. > > The conundrum is protecting users from self-injury versus unleashing the > full > power of the combined mechanisms. > > > > I can accept some mechanism for the sender to say "SPF only", "DKIM > > only", or "either SPF or DKIM". I cannot except a version of DMARC > > where *both* must pass. > > > Frankly, I cannot imagine the usefulness of auth=spf only. People who > don't > implement DKIM or don't like it don't bother publishing a policy to > explicitly > excluding it. It's enough not to sign. Excluding DKIM would be useful if > keys > have been compromised, an they have a long lifetime while, by chance, > DMARC > policy is given with TTL 3600. It doesn't seem to be realistic. > > Still, I'd allow that possibility for symmetry reasons. > > > 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
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote: If we consider this sort of thing, I want to push to keep one thing off the table: Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach. Let's please just remove that from consideration. It has not been in DMARC up to this point, and it would be really bad to add it. Deliverability would be worse than ever because we would get the worst of both: fragility of SPF when messages are relayed/forwarded, *and* problems caused by misconfigurations in *either* SPF *or* DKIM. I agree it'd be an extreme setting. It could only make sense in very extreme cases. However, in those cases it might make sense. In addition, if ARC-driven forwarding setups will gain the ability to override DMARC, at least for established forwarding paths, the forwarding prohibition would then be softened. After all, spf-all requires a comparable behavior (except that SPF allows intermediate results) and many domains use it satisfactorily. The conundrum is protecting users from self-injury versus unleashing the full power of the combined mechanisms. I can accept some mechanism for the sender to say "SPF only", "DKIM only", or "either SPF or DKIM". I cannot except a version of DMARC where *both* must pass. Frankly, I cannot imagine the usefulness of auth=spf only. People who don't implement DKIM or don't like it don't bother publishing a policy to explicitly excluding it. It's enough not to sign. Excluding DKIM would be useful if keys have been compromised, an they have a long lifetime while, by chance, DMARC policy is given with TTL 3600. It doesn't seem to be realistic. Still, I'd allow that possibility for symmetry reasons. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
Just to clarify something: On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba wrote: > I can accept some mechanism for the sender to say "SPF only", "DKIM > only", or "either SPF or DKIM". I cannot except a version of DMARC > where *both* must pass. > I think the proposal before us is to allow the domain owner to indicate it wants specific combination(s) of SPF and DKIM to pass in order for DMARC to pass. I imagine the default would be "or" which is backward compatible with what we have today, as the charter demands. Are you saying you don't even want "and" to be an option if it is made configurable? Or do you just not want the "or" to change to "and" without the proposed new tag? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
Barry, I understand your concerns. Use SPF *and* DKIM could cause issues for any kind of mail conferencing and forwarding. Situation are quite complicated right now. Use of these method, as well as combination of these methods, could lower deliverability due protection mechanism contrary of forwarding/conferencing principle. But the goal of protection methods is to ensure the authenticity of the e-mail source. This means that the sender is responsible for protecting the domain/brand. And this ultimately requires that the owner has methods that are able to provide enough data to ensure its full verifiability. Whether these methods are properly implemented is the responsibility of the sender's system administrator, whether they are checked upon receipt is the responsibility of the recipient's system administrator. Some of organization checks SPF only, some DKIM only, some SFP then DKIM, some SPF and DKIM (but logic of that use OR), in few tenth of precents also followed by DMARC. And some of organizations still does not check anything. Please, can you consider the possibility that the owner of several hundred or even several thousand domains is trying to protect his business and does not have the possibility to provide verifiable authenticity? If he understands the situation with their impacts, the possibility of using SPF and DKIM is a method to ensure adequate protection. By this I mean protection from where the mail can be sent and at the same time whether it will be signed. Despite the problems with mail conferences and forwarding, this may be an acceptable way to solve specific problems. In other cases, how we can mitigate as much of situation mentioned above? If the possibility of using only DKIM, I see the risk of how the DMARC policy will be evaluated. If the error state of the policy is ensured for specific cases (non-existent public key, non-existent subdomain, non-existing signature), I have no problem with the approach. All that is needed to ensure is a precise procedure, what conditions the implementation must meet. And we need method, how we can enforce use of DKIM, else we will be in situation without any protection. This is a reason, why I concern about protection. Regards Jan Dne 26. 6. 2023 v 14:51 Barry Leiba napsal(a): If we consider this sort of thing, I want to push to keep one thing off the table: Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach. Let's please just remove that from consideration. It has not been in DMARC up to this point, and it would be really bad to add it. Deliverability would be worse than ever because we would get the worst of both: fragility of SPF when messages are relayed/forwarded, *and* problems caused by misconfigurations in *either* SPF *or* DKIM. I can accept some mechanism for the sender to say "SPF only", "DKIM only", or "either SPF or DKIM". I cannot except a version of DMARC where *both* must pass. Barry, as participant On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko wrote: Hector, I think Levin's original suggestion to use the setting option like SPF AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve a lot of problems. System administrators know best how to set up their system and for what purposes they need that setting. I can imagine a great many reasons for and against those combinations. What seems to me to be important here is that DMARC is able to use policies to solve not only common but also error states. In that case, it is able to successfully solve the problems caused by the attackers. Jan Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a): Levine makes a good point. A less complex option would be: auth=dkim # apply dkim only, ignore spf, dkim failure is dmarc=fail auth=spf# apply spf only, ignore dkim, spf failure is dmarc=fail the default auth=dkim,spf SHOULD NOT be explicitly be required. It adds no additional security value. I would like to note that some DNS Zone Managers with DMARC record support will add the complete tags available for the protocol with the default conditions making the record look more complex than it really it. Other system integration options would (forgive me for I have sinned): atps=1 # we support ATPS protocol for 3rd party signer. rewrite=1 # we are perfectly fine with Author Rewrite -- HLS On 6/22/2023 10:18 PM, John Levine wrote: It appears that Emil Gustafsson said: I don't know if there is a better way to encode that, but I'm supportive of making a change that that would allow domains to tell us (gmail) that they prefer us to require both dkim and spf for DMARC evaluation (or whatever combination of DKIM and SPF they desire). I really don't understand what problem this solves. More likely people will see blog posts telling them auth=dkim+spf is "more secure", they'll add that without understanding what it means, and all that will happen is that more of their legit mail will disappear.
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
On June 26, 2023 12:51:06 PM UTC, florian.kun...@telekom.de wrote: > >> In theory, DKIM is enough for DMARC (this was always true), but in practice >> it >> is not. > >May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job, >but people here expect to apply it to solve real problems with real email in >real life. >*SCNR* ... do not take that personally. > > >> I don't think there's evidence of a systemic weakness in the protocol. We've >> seen evidence of poor deployment of the protocol for SPF, but I think the >> solution is to fix that (see the separate thread on data hygiene). > > >The problem with DMARC is, there's no easy way to decide you can rely on SPF >as long as it references shared IP infrastructure (because you can't decide >whether an IP is shared or dedicated). >In my view this is a tremendous weakness of the SPF protocol. >(maybe only 'cause I do not trust shared infrastructure providers to get their >customers right all the time, 'cause I know how hard that is from being an ISP >mailer) > >So to remove or at least ignore SPF from DMARC is minimal requirement for >DMARC being worth mentioning supportive of sender authentication at all. >Meanwhile it's a pretty viable attack vector against DMARC, foiling the idea >of sender authentication. That's true if you change the semantics of what a DMARC pass means. It means it came via an authorized source. It does not mean anything about if the message is "good" or "bad". It doesn't and can't solve the problem of inappropriately injected mail in the authorized stream. When a domain publishes a public key in its DNS that's been given to it by a third party provider, DKIM is also exposed to third party provider data hygiene risks. Even if DKIM were perfect and we ditch SPF, users get compromised and bad stuff still gets into the authenticated stream. I think people are attributing a lot of badness to SPF when it's a more general problem. It's just easier to identify with SPF. Currently, bad ingress controls for third party providers mostly imposes external costs (from their point of view). Until that changes, it will be a mess no matter what the underlying authentication technology is. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
> In theory, DKIM is enough for DMARC (this was always true), but in practice it > is not. May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job, but people here expect to apply it to solve real problems with real email in real life. *SCNR* ... do not take that personally. > I don't think there's evidence of a systemic weakness in the protocol. We've > seen evidence of poor deployment of the protocol for SPF, but I think the > solution is to fix that (see the separate thread on data hygiene). The problem with DMARC is, there's no easy way to decide you can rely on SPF as long as it references shared IP infrastructure (because you can't decide whether an IP is shared or dedicated). In my view this is a tremendous weakness of the SPF protocol. (maybe only 'cause I do not trust shared infrastructure providers to get their customers right all the time, 'cause I know how hard that is from being an ISP mailer) So to remove or at least ignore SPF from DMARC is minimal requirement for DMARC being worth mentioning supportive of sender authentication at all. Meanwhile it's a pretty viable attack vector against DMARC, foiling the idea of sender authentication. Florian ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
If we consider this sort of thing, I want to push to keep one thing off the table: Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach. Let's please just remove that from consideration. It has not been in DMARC up to this point, and it would be really bad to add it. Deliverability would be worse than ever because we would get the worst of both: fragility of SPF when messages are relayed/forwarded, *and* problems caused by misconfigurations in *either* SPF *or* DKIM. I can accept some mechanism for the sender to say "SPF only", "DKIM only", or "either SPF or DKIM". I cannot except a version of DMARC where *both* must pass. Barry, as participant On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko wrote: > > Hector, > I think Levin's original suggestion to use the setting option like SPF > AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve > a lot of problems. System administrators know best how to set up their > system and for what purposes they need that setting. I can imagine a > great many reasons for and against those combinations. What seems to me > to be important here is that DMARC is able to use policies to solve not > only common but also error states. In that case, it is able to > successfully solve the problems caused by the attackers. > > Jan > > Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a): > > Levine makes a good point. A less complex option would be: > > > > auth=dkim # apply dkim only, ignore spf, dkim failure is > > dmarc=fail > > auth=spf# apply spf only, ignore dkim, spf failure is > > dmarc=fail > > > > the default auth=dkim,spf SHOULD NOT be explicitly be required. It > > adds no additional security value. I would like to note that some DNS > > Zone Managers with DMARC record support will add the complete tags > > available for the protocol with the default conditions making the > > record look more complex than it really it. > > > > Other system integration options would (forgive me for I have sinned): > > > > atps=1 # we support ATPS protocol for 3rd party signer. > > rewrite=1 # we are perfectly fine with Author Rewrite > > > > > -- > > HLS > > > > > > > > > > > > On 6/22/2023 10:18 PM, John Levine wrote: > >> It appears that Emil Gustafsson said: > >>> I don't know if there is a better way to encode that, but I'm > >>> supportive of > >>> making a change that that would allow domains to tell us (gmail) > >>> that they > >>> prefer us to require both dkim and spf for DMARC evaluation (or > >>> whatever > >>> combination of DKIM and SPF they desire). > >> I really don't understand what problem this solves. More likely people > >> will see blog posts telling them auth=dkim+spf is "more secure", > >> they'll add that without understanding what it means, and all that > >> will happen is that more of their legit mail will disappear. > >> > >> If you're worried about DKIM replay attacks, let's fix that rather > >> than trying to use SPF, which as we know has all sorts of problems of > >> its own, as a band-aid. > >> > >> R's, > >> John > >> > >> ___ > >> 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
