On Mon, Jul 3, 2023 at 10:29 AM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote:
> > > > On Jul 3, 2023, at 10:06 AM, Barry Leiba <barryle...@computer.org> > 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