Re: [Ietf-dkim] DMARC's auth=dkim+spf tag
On Mon, Jul 3, 2023 at 10:29 AM Hector Santos wrote: > > > > On Jul 3, 2023, at 10:06 AM, Barry Leiba > wrote: > > > >> Anyway, discussing whether spf+dkim verification can mitigate DKIM > replay > >> belongs to the ietf-dkim list. (In case, it could also be expressed > outside > >> DMARC, for example by an additional DKIM tag.) > > > > I do agree with this, yes. > > > > +1 > > There may be additional integrated protocol considerations for ESMTP, SPF > and DKIM that may go beyond what DMARCbis is willing to consider. > > — > HLS > > > +1 We should consider creating some new authentication method resistant to replay and forwarding attacks, and update DMARC at some future point to support that as a 3rd authentication method. Such a technique should also be tolerant of forwarding potentially over multiple hops, with message modification. In the past, at this point John Levine has said in the past that why not also ask for a pony too. Yes, understood, this is a lot. Potentially we can extend the Replay Resistant ARC draft to act as a message authenticator for this role. Yes it's complicated, and yes we need to see if it will work on actual traffic, hence the ongoing prototyping work on the DARA concept there. We welcome consideration of other approaches or feedback for improving DARA. In that draft there is an idea to integrate the validation into ESMTP called SeRCi but some months back when looking at DARA vs SeRCi, we thought DARA would be less burdensome for us and others to implement. Assume for a moment that the DARA experiment works out. It's our hope is that the proposed "auth=" tag in DMARCbis ought to be designed in a way that permits future authentication methods. As to supporting "spf+dkim" for the proposed DMARCbis "auth=", and other potentially other authentication policies, let's consider the needs of different classes of senders. - Sender using dedicated MX that doesn't care about mail forwarding- can use default DMARC authentication (DKIM or SPF), or explicitly specify for "auth=spf" - Sender using shared MX or cares about supporting forwarding- specify "auth=dkim" - Potentially such a sender may want to support forwarding with message modification when possible. Propose that "auth" allows an OR'ed evaluation between authentication methods, and in this scenario specify "auth=dara,dkim". In this model, a receiver that doesn't understand an authentication method is allowed to ignore the requested method. - High risk sender subject replay and SPF upgrade attack and wants to protect its reputation to ensure deliverability- specify "auth=spf+dkim". Such a sender sacrifices forwarding for deliverability. - Potentially the high risk sender might want to also specify DARA as another option to support forwarding when possible, and that can be specified as "auth=dara,spf+dkim" -Wei ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DMARC's auth=dkim+spf tag
> On Jul 3, 2023, at 10:06 AM, Barry Leiba wrote: > >> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay >> belongs to the ietf-dkim list. (In case, it could also be expressed outside >> DMARC, for example by an additional DKIM tag.) > > I do agree with this, yes. > +1 There may be additional integrated protocol considerations for ESMTP, SPF and DKIM that may go beyond what DMARCbis is willing to consider. — HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DMARC's auth=dkim+spf tag
> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay > belongs to the ietf-dkim list. (In case, it could also be expressed outside > DMARC, for example by an additional DKIM tag.) I do agree with this, yes. Barry ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DMARC's auth=dkim+spf tag
On Fri 30/Jun/2023 19:22:28 +0200 Barry Leiba wrote: Ale, you're venue-shopping; please don't do that. Sorry, I understood the discussion was banned from the dmarc list. In fact, messages that would only be blocked by auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages that pass SPF but fail DKIM. Since the latter case, excluding misconfigurations, looks unlikely, this settings serves only DKIM replay. > What you say here about DKIM replay is misleading and wrong. Barring misconfigurations, "dkim+spf" would be equivalent to "spf", as you actually point out in the paragraph above, and it has nothing to do with mitigating DKIM replay An example of SPF pass where DKIM does not is a domain that uses an external smarthost, at least for some targets which blacklist its IP addresses. A serious but non-exclusive smarthost can promptly identify abuse culprits, but may not be able to prevent them. So checking DKIM in addition to SPF would bring an added value in such cases. (other than to say that the way to avoid DKIM replay is not to pay attention to DKIM). That agrees with the initial remarking that DKIM replay is a feature, not a bug, as it is consistent with the the by-design independence from transport details. In any case, if anyone is interested in discussing this DMARC protocol proposal, please go to the DMARC list, where it is actively being discussed. Anyway, discussing whether spf+dkim verification can mitigate DKIM replay belongs to the ietf-dkim list. (In case, it could also be expressed outside DMARC, for example by an additional DKIM tag.) Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DMARC's auth=dkim+spf tag
Ale, you're venue-shopping; please don't do that. > Discussions about solutions that only cover DKIM replay are now declared to be > out of scope for DMARC. In fact, messages that would only be blocked by > auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages > that > pass SPF but fail DKIM. Since the latter case, excluding misconfigurations, > looks unlikely, this settings serves only DKIM replay. So I turn the topic to > this WG, in case someone thinks it's worth mentioning it among the possible, > yet untried solutions. Just as solving DKIM replay is out of scope for the DMARC working group, I hope the DKIM chairs will agree with me that changes to the DMARC protocol are out of scope here. What you say here about DKIM replay is misleading and wrong. Barring misconfigurations, "dkim+spf" would be equivalent to "spf", as you actually point out in the paragraph above, and it has nothing to do with mitigating DKIM replay (other than to say that the way to avoid DKIM replay is not to pay attention to DKIM). In any case, if anyone is interested in discussing this DMARC protocol proposal, please go to the DMARC list, where it is actively being discussed. Barry, DMARC chair ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DMARC's auth=dkim+spf tag
Hi, for those of you who don't subscribe to dm...@ietf.org, I resume this proposal, which was aired there last week. The idea is to let a domain specify which mechanisms to consider when validating DMARC alignment. The default would be auth=dkim/spf, meaning that either an aligned signature or an aligned SPF address would validate a message, as is now. Setting auth=dkim only would change it to discard SPF results. It could be the choice of domains who are forced to include an over-bloated SPF record, which is needed to deliver to some non-DMARC receivers, but allows impersonations. Choosing auth=dkim+spf would require both DKIM /and/ SPF to validate. That would exclude DKIM replay from unauthorized sources. Would it work? The effect could be compared to that of receivers who reject spf-all before DATA, hence before evaluating DKIM, and then would reject on failing or non-aligned DKIM. The absence of softfail (~all) for DMARC would make the combined method even more severe, to the point that it's been called a footgun. Discussions about solutions that only cover DKIM replay are now declared to be out of scope for DMARC. In fact, messages that would only be blocked by auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages that pass SPF but fail DKIM. Since the latter case, excluding misconfigurations, looks unlikely, this settings serves only DKIM replay. So I turn the topic to this WG, in case someone thinks it's worth mentioning it among the possible, yet untried solutions. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
