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

Barry Leiba <barryleiba@computer.org> Fri, 09 June 2023 08:34 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 9B2E8C1519AD for <dmarc@ietfa.amsl.com>; Fri, 9 Jun 2023 01:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.553
X-Spam-Level:
X-Spam-Status: No, score=-1.553 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DyKSmh_xdNQb for <dmarc@ietfa.amsl.com>; Fri, 9 Jun 2023 01:34:10 -0700 (PDT)
Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (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 25EE8C1519AB for <dmarc@ietf.org>; Fri, 9 Jun 2023 01:34:10 -0700 (PDT)
Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-97467e06511so267866966b.2 for <dmarc@ietf.org>; Fri, 09 Jun 2023 01:34:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686299648; x=1688891648; h=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=1kNI0Nlh0BI0aiXTtw9RO6s2nJiBWS44hqFVyw1QraU=; b=h44D2Q7/dxTmdw2s0drfwAKF8RtR8vd6ZyEtgFgdWwW6CmuuuV49EzcfGwCL32GUQm W55UTBzE5HQw/iAjWGAB3JQwGXl4IaOodoYcH1YB1lGtBK/7KbfxyjmMIIrxmjspCP/A tIw82rcpj9DK5ZThMKlmH/U682WHCQgoSJ5fW1PvYtCvDgtiOpq0h388nOjNrsw7NchL 9K0aFpFPlybvIcLfT6w5vxjgscBFdDSCBHTBMVdKfw9jzMSb9TT8b02jAht3w/PMwAcN Q7XWtPMUEi39iA8QCAtaScIIyosr2f1Qsa14ugW32dAjmHS0gwd2xMdQX4OXpGohii17 /pag==
X-Gm-Message-State: AC+VfDyNDcADX/AXZDf6ognovPiNnTFLnWrXEXZ82OttDAXzI+yKRhMQ Vv3wpou5I/ObE8LVV/5N+7vhqWiKUfdMX/NPV2rELTAlqAApGg==
X-Google-Smtp-Source: ACHHUZ5ETTuupT0LRAsPGVcHh5T5qCVVOx4w1c9z+aNBe7xuNIDg80KcKbtMeRolgALm1PJaOrM06MZxkgJijuTeEg8=
X-Received: by 2002:a17:907:7ba9:b0:978:62c1:6b4b with SMTP id ne41-20020a1709077ba900b0097862c16b4bmr1421036ejc.61.1686299648315; Fri, 09 Jun 2023 01:34:08 -0700 (PDT)
MIME-Version: 1.0
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <CAL0qLwbx6Y=kmB5pQZx8gNqD=rLBYz1vLOX6ngL=wUHHUm0Hjw@mail.gmail.com> <CAOZAAfMtsjcp+aCrwQ2QRc+SHsw3rhwMuTBugRYe44NeiMeKyg@mail.gmail.com> <CALaySJKrXJJXz3pgp85BPswoirhPJtD=uuefVfc9sX1fGkj-iA@mail.gmail.com> <CAJ4XoYc++Ossx-1oAX6fK12a3v=yz8XhoXKHdNF7-e8p=O3OCA@mail.gmail.com> <CALaySJJU+AAbfYnzm2vHGNzo-BpEHAVUxTw_HmrvDo414MKq+g@mail.gmail.com> <2AC14310-16EC-43A9-B95E-BAE7E5C78FDA@kitterman.com> <CALaySJLtumxWU2A_ae9oipuebaHn0qDO52TCDYPM1v50NcBq-g@mail.gmail.com> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com>
In-Reply-To: <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 09 Jun 2023 09:33:54 +0100
Message-ID: <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dmarc@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/xXdYnNpr6aZPZs8Vl0ENrAs6ODU>
Subject: Re: [dmarc-ietf] 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: Fri, 09 Jun 2023 08:34:10 -0000

I think, Scott, that you and I have a fundamental disagreement that's
not resolvable, and I won't just repeat what I've already said.  But a
couple of the things you said are ones I can't make sense of, so I'll
talk about those:

> Software engineering isn't a perfect science.  In general, a more
> complex protocol will suffer more defects.  If you want to design
> things that only work when software is perfect, I'm not interested.

It seems that you're saying you're "not interested" in any protocol
that won't work if there's a software bug, and that makes no sense to
me.  Crypto is hard to get right and there are often bugs; TLS won't
work if you don't get the crypto right: does that mean you're not
interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
because it will fail if there's a bug in the network stack?  For that
matter, a router with a bug in its MPLS implementation won't work:
should we not use MPLS?  And, well, if there's a bug in your
SPF-record parser, SPF won't work either, n'est-ce pas?

Of course, the level of failure in any of this depends upon just what
the bug is.

> One could make the opposite argument too, and I think it would be
> equally valid:
>
> The only value DKIM brings for DMARC is for indirect mail flows.  For
> any direct connections, SPF is sufficient.  All the proposed DKIM
> changes to solve the DKIM replay problem are likely to break indirect
> mail flows anyway, so there's no longer a point to keep DKIM.  It's
> much more complicated and it looks like the benefit of it is going
> away, let's just simplify the protocol and get rid of it.

This also makes no sense, as it completely misrepresents the situation
I'm raising.  It *doesn't* work both ways, because DKIM works in all
situations that SPF does, but it *also* works in some situations where
SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
does.  SPF does not add value, ever.

You and Mike seem to be holding on to SPF because you want to, with
some vague "I've seen network errors and software errors" statements
but without real arguments.  The only real argument I've seen is
Seth's about broader deployment of SPF without DKIM.  I've already
said why I think that's not a reason we should keep SPF, but at least
that is a reason I can make sense of.

Barry