IETF Logo Mail Archive

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

Emanuel Schorsch <emschorsch@google.com> Thu, 29 June 2023 01:07 UTC

Return-Path: <emschorsch@google.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 635C2C14CE38 for <dmarc@ietfa.amsl.com>; Wed, 28 Jun 2023 18:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.596
X-Spam-Level:
X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 9cwq8YQZlifg for <dmarc@ietfa.amsl.com>; Wed, 28 Jun 2023 18:07:51 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 94204C14CF05 for <dmarc@ietf.org>; Wed, 28 Jun 2023 18:07:51 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-98df3dea907so16101366b.3 for <dmarc@ietf.org>; Wed, 28 Jun 2023 18:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688000869; x=1690592869; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dnAH5RpfVXIYxV8rZU3w94Oc5HWFrhrkPkEGNUVyIEg=; b=XzHfUtrGHffx/4aY6C11evpZdkGseSsidpH+/6t+cbOlMnRyHAINJN9iTPi7/0bZex a25eFWW+PFiQT2t+hox8w13fM0EODXNhgp3UjV8n1qG7Udr8SNmdTI8IA4DvS1Yieqq6 W02ZyIztRxZDRj89bXDd+m05HK1/RXs17676zXHNDJKIrjaXZCSuHaptXQVUtwr74Krl bgNIyP74ir5irp7JupGb0uCPtEGjIns8c6xCb2fUM5crjuP6nxk+8FiRYmWSXn4TppJb toFY3BEY9PhZx9JxNCn8PhQgZ5tlBtMdOU52l3FqrCYxQU6tgDVYdiPGihOQ0gFH1kc5 KBgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688000869; x=1690592869; 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=dnAH5RpfVXIYxV8rZU3w94Oc5HWFrhrkPkEGNUVyIEg=; b=jOVQE5xWKvv9bRl4vpg/852CZ8bBa4gNOXS2cFvaJAwIEbWxfxDArjhDuinJOaLX3k HQKDcm7Gb74uQ1mYrQ5PCLI+Vzkq+wt6u4vtMmIoqGQfouD267esMBqkHtKcIFJfWuf4 rlw5rnDu8EzeTZHJrCGqEJnXYDkcVFlUXye0r0JYxjnX1WG5N6ZgbYlcRnPEWkYh0to0 sCbmxR/YzUt0Rxt2C+ym5DwQf8AxBDsrr7w9ZUxq+MDEPA4g42C58hkLQvYmjdC+LORe VjigvS/VN4bCVTp6dPV4T0862CBxly0vqU7qFV2PGP9ZtJKp3TvUoB4ddXXjcdmkTjqx n9FQ==
X-Gm-Message-State: AC+VfDzHWw0EhFsiCFnmiNEBY3m1wNZOkzWA90fsa0trOO82bfDBeBs/ SDc92D8es9Ei3NuEIa9SwKSc4AY6AE+1K2gcegZUQA==
X-Google-Smtp-Source: ACHHUZ6AUzDTHbFA/gFrXx/ZUp1yZR8RpYremMcfWN7f+inlSRhoWi4JucWEEv5WG48frsIRtSnQVVZD/DCpwcixanc=
X-Received: by 2002:a17:907:2bf4:b0:978:62c1:6b4f with SMTP id gv52-20020a1709072bf400b0097862c16b4fmr8994581ejc.12.1688000869254; Wed, 28 Jun 2023 18:07:49 -0700 (PDT)
MIME-Version: 1.0
References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org> <CALaySJ+gcVvpzJcrpUbOkOvjUFAhzw=pZovpZC7BhW_x7VW7nA@mail.gmail.com> <CAL0qLwasxzqJt7Hr7gZd86C=ivCrDUci_i6pkJJUTnqzL1pHMA@mail.gmail.com> <CALaySJ+gjR6D-OSE_07iSH2zXa7wypUQwPN1cL-1s+NC2S4L8g@mail.gmail.com> <99e1ef2d-053b-8cfe-f369-fa8475d142ae@tana.it> <CALaySJKZoAPTT-+cZEww+y2eUsDbNXcybb=Z7RxNLyfzPMr7ng@mail.gmail.com> <d3986316-02f9-9d73-be81-37af7cfd40a7@tana.it> <CALaySJLtUtKNtP4__pOryFLaAODjiEx-nbdvF9tL6wYhcRCe_g@mail.gmail.com> <877A1137-3A55-424A-A9C5-FCCA4F2D5436@kitterman.com> <CAH48Zfyp1CvKLaGvYp0eC=E3hG7GU-T2YGR+H64GMzSNjM3AAA@mail.gmail.com>
In-Reply-To: <CAH48Zfyp1CvKLaGvYp0eC=E3hG7GU-T2YGR+H64GMzSNjM3AAA@mail.gmail.com>
From: Emanuel Schorsch <emschorsch@google.com>
Date: Wed, 28 Jun 2023 18:07:11 -0700
Message-ID: <CAFcYR_VhM4tsop7WwLZaLY6JhDJBiGO4E96HLzm4eqbdR+U3Pw@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031d38f05ff3a544f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/qlc9KL5XRdC738mM5AUnwnvT-MU>
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: Thu, 29 Jun 2023 01:07:55 -0000

On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
dougfoster.emailstandards@gmail.com> wrote:

> We are talking about SPF AND DKIM because of the problems with DKIM
> replay.   Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>

I'll clarify how I view SPF AND DKIM in relation to DKIM Replay. Let's use
bob.com as the domain:

   - If DK=bob.com and SPF=bob.com then NOT dkim replay.
   - If DK=bob.com and SPF!=bob.com then MAYBE dkim replay (of course
   probability of dkim replay varies widely, and could still be 0 for this
   particular SPF)
   - If DK=bob.com and SPF!=bob.com and DMARC policy is SPF AND DKIM then
   LIKELY dkim replay if seen in large volumes.

So the value of that DMARC policy for DKIM Replay is that bob.com can be
better protected against heavy replays because they have a way to say "I've
checked all my direct flows have SPF AND DK aligned. If you see mail with a
different SPF you can be sure it's an indirect flow and be more aggressive
about quota limiting large volumes."

To be clear, that would be a benefit for protecting aligned domains that
are replayed, but I'm NOT suggesting this is enough benefit to allow users
to set SPF AND DKIM for a DMARC auth policy. I agree with others that it's
a footgun, and it would be better to convey this information in some other
way.

v2.23.0 | Report a Bug | By Email