[dmarc-ietf] Design choices and shortcuts

Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 19 June 2022 21:24 UTC

Return-Path: <dougfoster.emailstandards@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 B8393C14F749 for <dmarc@ietfa.amsl.com>; Sun, 19 Jun 2022 14:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RdLcEY_kNMHa for <dmarc@ietfa.amsl.com>; Sun, 19 Jun 2022 14:24:33 -0700 (PDT)
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 473A7C14F73B for <dmarc@ietf.org>; Sun, 19 Jun 2022 14:24:33 -0700 (PDT)
Received: by mail-oo1-xc2b.google.com with SMTP id n24-20020a4ae758000000b0041b82638b42so1782210oov.9 for <dmarc@ietf.org>; Sun, 19 Jun 2022 14:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=jH9sBuTigSEOwGAJMx9EvuEnpxmUMEDomHwB2/paP2g=; b=XaCe+FYS/G6AAt8HFEPQNpW4bmU+Y3KBlhjUhnq5u4pBoMZuL5LqyhjWXiBkpzl5nM Gsv5iqggVE2sHwL/I2q76hFnEFUCGCB9e8avybI1YR6KbnyJcxUgLSF796BjiexZ33yh m/3jQsXX2c2UCUV+N4tOMw1ZZdG0uwr6+OLg3/Wsbw4aqoqC4GpTzA4GoX+emmq/7v0L MSOPdW8qCs2dx6xXIBJrgfGSVFPle5E9FowFyvsmLtE3q9CT+S0oXkg3APvLVlc6DauE Ob0WlhzepfWqeDLO3m+5pTN92WIha0PqYKs0UNEVvcQeVG5vVdZxW9CzqyM24XoT2py3 UxPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jH9sBuTigSEOwGAJMx9EvuEnpxmUMEDomHwB2/paP2g=; b=PvL4BKGuLxEpogjqak5ziQVKaswaMsc8RcJNPUQoUE+nCgKlt3kg7h1IRsYxaqZEWm N3T8ao+NcsFHh+G7oxOg+N6VJTc8cYiIuZXNC/HpffKGJGM8LJ8I1nfIhzsoaWUx74Rw PUyVvlR7LnJQItbKVkAdRU6qQykPbM6RlJp3CAwVPrCgiExnwFM0tBK96ePdQ2pLK67l mTeA4b7xuy7rRNmUiRDDVhbApPC7OMmRGhWTgsgSJVtA6Mm7A+aXAa2OfNaSdWuKozvf 82pfv3x0DuV7IvPxXmayN5WuK/tmq0A8NyWgQbBHQAMWzW7Hx1rWwlkPlLJTiBlksrCn htXg==
X-Gm-Message-State: AJIora8st+9kPbBuZaLrqwFFT6xaHbXFNOb1bdxE6FjMa/wuFc4Y2SCJ P/HItB9gZ2X570bZLw9OVxUW4rqPQpzerwFJzReAiZJOhXY=
X-Google-Smtp-Source: AGRyM1vgrZJmw/q7MGTd56EdDhtjHeM/pBDSFYwyTjHmzFLHnUGxFy9qOshKaK06JzWs1aeryMbRQZ6nVo9BHFyesOY=
X-Received: by 2002:a4a:e558:0:b0:41c:f4e:1540 with SMTP id s24-20020a4ae558000000b0041c0f4e1540mr7806576oot.15.1655673872099; Sun, 19 Jun 2022 14:24:32 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sun, 19 Jun 2022 17:24:22 -0400
Message-ID: <CAH48Zfy4t3DHBXBwHKhdOQ8C0+VhKugxL3djFHOuvctbNCrvsQ@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002ae0e05e1d39d46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MRswyOsJs-u2q6dEQIuRYvSk73s>
Subject: [dmarc-ietf] Design choices and shortcuts
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: Sun, 19 Jun 2022 21:24:33 -0000

I fully support replacing the PSL with organization boundary information
provided by domain owners and registrars, as that data becomes available.
We have good theoretical reason to conclude that domain owners and
registrars have the best knowledge about boundaries, and appropriate
incentives to report it correctly.  This appeared to be the original
proposal, but we have diverged from that starting point.

The mechanisms for communicating boundary information are what we are
developing, so the current DNS does not contain any such information.
Missing data means that the replacement of the PSL with DNS information
could take a long time, which is undesirable.

The current discussion attempts to circumvent that long rollout with a
shortcut.   It replaces the PSL immediately, using a heuristic and a small
amount of new information from registrars.  By itself, the heuristic
creates a known vulnerability – false PASS results caused by undetected
organization consolidation.    To work around the problem, the WG will
ensure that key registrars publish essential boundary information prior to
publication.   Instead of replacing information with better information, we
are replacing one type of expert opinion, the PSL, with a different type of
expert opinion, a WG assertion that the DNS will contain sufficient new
information to make the new heuristic reliable, as of publication date.

My problem with this approach is that the published RFC needs to last 30
years or so.    What mechanism will ensure that the DNS remains compatible
with the heuristic for the 10,000 days after publication?    The WG spin up
a volunteer committee to monitor the Internet and publish information
evaluators need to assess risk, but that is not going to happen.   We would
be replicating most of the problems of the existing PSL, and we do not have
a plan in place to make it happen.

As an evaluator, I find a shortcut based on a heuristic to be unacceptable,
because it is inherently unsustainable.   When the publication-date
assumption ceases to be valid, my recipients become vulnerable.    We need
to replace imperfect PSL information with more reliable information,
provided by the domain owners and registrars, and provided using tokens
that eliminate questions about whether critical data is still missing.

My previous question about Evaluator motivation was a setup for this
topic.   If a problem is perceived as acute, alternatives do not have to be
optimal to be acceptable.    But since the problem appears to be important
but not urgent, we should proceed to a more reliable solution which is
devoid of guesswork.

To ensure that the transition does not last forever, we need to publish the
new algorithm and the new tokens, insist that evaluators use the new tokens
when they are available, and put a sunset data on the old algorithm.    The
sunset provision says that after a specific date, DMARC policies which lack
DMARCbis tokens SHOULD be evaluated using strict alignment.   Strict
alignment is always safe.