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
