Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

Barry Leiba <barryleiba@computer.org> Mon, 26 June 2023 12:52 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC29CC13AE21 for <dmarc@ietfa.amsl.com>; Mon, 26 Jun 2023 05:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGPOWakPpbFq for <dmarc@ietfa.amsl.com>; Mon, 26 Jun 2023 05:52:20 -0700 (PDT)
Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E809C151070 for <dmarc@ietf.org>; Mon, 26 Jun 2023 05:51:48 -0700 (PDT)
Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2b6a152a933so14101271fa.1 for <dmarc@ietf.org>; Mon, 26 Jun 2023 05:51:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687783906; x=1690375906; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FNTQ9C4lKnSNmCTdQz+we8iijIui71uHxpIQRjRY7ro=; b=AYFkPkHww3PST4+sHp/Q2MpYY3vaJppYQfQtyHMXqqp+jm4UaFQUWq9nGFQqAlMkXp LKmXZ6XvZi75/X/fV/Jv/zr0Dw9L4g44Ekk7KDQOSw+O2mzmoqPvpB9JmkPMuy5o2k/X WgGDqtfFX2EXbAEC13J1lwPQ5M3RIb/i5Umb1beqPGnNHWqNfQM/5+rPrDIcxElh9nDh 4+S55Bli0EFzdhOy1BEhDLpFpWG5YCl4zd5gLFdWJA2q/cB2LkPMcVYqpKAcqzGNjjf+ Bkabpl7vJOzwSqB9O8ZNWdbMNobghciO6kRjrX0yFoXgYrc0zee3tWeAc64mNBpVsJTH ZzzA==
X-Gm-Message-State: AC+VfDz7wPNnlGB3HNWJjPDPrDfiAmMtXsSQNpMcPXe84nNqx10XMUKW xrs7PCry2RC4y+1d/k46EcOPsFGZ4mU2ifAcOFQZ2eLp
X-Google-Smtp-Source: ACHHUZ4BgcsJ5dSVhbyKTxuYBv9/5Xc8HaJEobBDqxm27UsVkfDQZWvBF3pizzcrrADXKttnKr///vXkIBKF1RNbm30=
X-Received: by 2002:a2e:9b85:0:b0:2b4:7d67:7881 with SMTP id z5-20020a2e9b85000000b002b47d677881mr14106751lji.25.1687783905975; Mon, 26 Jun 2023 05:51:45 -0700 (PDT)
MIME-Version: 1.0
References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org>
In-Reply-To: <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 26 Jun 2023 08:51:34 -0400
Message-ID: <CALaySJ+gcVvpzJcrpUbOkOvjUFAhzw=pZovpZC7BhW_x7VW7nA@mail.gmail.com>
To: Jan Dušátko <jan=40dusatko.org@dmarc.ietf.org>
Cc: dmarc@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/KM7f7fbgmokTgozs2PbsLKq39K0>
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2023 12:52:20 -0000

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
<jan=40dusatko.org@dmarc.ietf.org> 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 <emgu@google.com> 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