[dmarc-ietf] Sibling Authentication

Douglas Foster <dougfoster.emailstandards@gmail.com> Thu, 01 June 2023 11:02 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 60536C14CE42 for <dmarc@ietfa.amsl.com>; Thu, 1 Jun 2023 04:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 n82RzAl5OMa3 for <dmarc@ietfa.amsl.com>; Thu, 1 Jun 2023 04:02:56 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 D20BCC14CE3F for <dmarc@ietf.org>; Thu, 1 Jun 2023 04:02:56 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2af20198f20so9530171fa.0 for <dmarc@ietf.org>; Thu, 01 Jun 2023 04:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685617374; x=1688209374; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=e4O13iLW4ji5SqYSPjFYwx69R/2odf2c1n2C2UUgyMU=; b=WuQZtBPG4mT2N46AHwWDE24Ay03wZkNJqR8Et83Lm9gx/vn1Wl1RbYF7CbK/GCDr/P Ycke8EUWqbwniPT7YqkyAibnOVzd6ZoWTogIcMD0ZueM55ODne3HKOv4ERaP7zYNjsli TaY/4GTe/zMYxVGRirI+JMjrMtcB9uAnF3VwT+XROsUxyxLedN0SZelzh3pzF3UhdjiB OGPQq2X+lLrskcjBXCSpT6b98JbuahYeN/+zoczfucOScsyedODdYTEiuJm4w3xIdktv EbdIBIVvrmsEzginfIpdlbPiuF0yrz4voP7zWVvWIvpVIrKX+pc7Z7KpjY1TRSe0qKrv aj7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685617374; x=1688209374; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=e4O13iLW4ji5SqYSPjFYwx69R/2odf2c1n2C2UUgyMU=; b=I0TQXNtZO139wzIPSlArc+g3E3qMlU/Em5MU0rrVu9kqFdABda8ycNrV2bnZfFSflW abaAUmv5AupOnGMt4I8YkUPAudUGgqmo0IyEADyjbqPQehVCiQPRqP+INoCbMrFL73zu rRQQkIcbxbPT1TSF7yyjXQh1cDYJQKSJAqThyoq8eZXoEgbOJqLELlTQUKhG/LqoXrMt IbN6iA3RFA1Fyb4XWbP5QDym+0ln1adqLH1ixlIpvr/Xpufp4RBIL/K1R1dWtwWPW5eB Ra71mECbd91B19gIkdWPf8UlCzSe8xsVCv/9G5Y5J9fHlfZ60IESxI8ZtBrRpicI0+2r XyRA==
X-Gm-Message-State: AC+VfDxjXsGXq6mEip11SW+rCH19bOdjlASiunI9mRxKSa7QwDIWc5Sp 3KA3o2faGQ2aiFQjGMzc4S4XAcqII8F9CXI/TvR1cNKEsU4=
X-Google-Smtp-Source: ACHHUZ5W5X8xgKPzWhAG0arJPFTJFqjG2bj1WInerLP+S+k2xhi6HKbOqsLC3nJgAlYvzPPjIJ5S03Y7jCBR3Kte3hM=
X-Received: by 2002:a2e:9f01:0:b0:2af:bf0d:e1c8 with SMTP id u1-20020a2e9f01000000b002afbf0de1c8mr4412072ljk.12.1685617374017; Thu, 01 Jun 2023 04:02:54 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Thu, 01 Jun 2023 07:02:43 -0400
Message-ID: <CAH48Zfym2GqK4XWaavVykoqfiscZms9CBUzuY9cg=98WS4Aipg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce57b505fd0f6040"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LGhvUF9tYm2kb5s5HrmS8Y2h0gc>
Subject: [dmarc-ietf] Sibling Authentication
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, 01 Jun 2023 11:02:57 -0000

I cannot support the current draft because it creates new problems without
sufficiently solving the old ones.

The PSL is subject to two types of errors:
- Landing too high, causing False Pass on non-affiliated domains
- Landing too low, causing False Fail or False NoPolicy on domains that are
actually affiliated.
False Pass presents the greater threat.  While it could occur on any type
of non-strict alignment, the primary concern is False Pass on sibling
alignment.

The bottom-up-first-stop tree walk attempts to solve the problem of False
Pass by using an algorithm that will often land too low, causing False
Fail.  Nonetheless, it fails to solve the whole problem because evaluators
are still at risk from private registries that publish a DMARC policy with
strict alignment but without a PSD tag. The proposed tree walk has other
problems, because it changes an organization's relaxed alignment boundary
every time that a policy is added or removed.  It also means that domain
owners must ensure that their policies and their configuration produce the
correct result whether the evaluator is using RFC 7489 or DMARCbis.

The PSL security problem is caused by relaxed alignment itself.  To be
secure, relaxed alignment requires a certainty about organization
boundaries which we cannot yet provide. The appropriate response is to
eliminate sibling authentication.  This change would provide immediate
protection for evaluators, with minimal changes to their running code.
For implementations that have an adequate DMARC exception process, sibling
authentication can be permitted for specific message sources using local
policy.   With this change in place, the differences between PSL lookup and
Tree Walk becomes much less important.

My data indicates that sibling authentication is so lightly used that we
will see minimal disruption to legitimate traffic, much less disruption
than will occur from the proposed tree walk.  I am hoping that Google can
provide more specific data about the use of sibling authentication under
different DMARC disposition policies.

As long as the parent-child and child-parent forms of relaxed alignment are
permitted, we need an explicit tagging mechanism which gives the domain
owner full control over alignment boundaries and eliminates uncertainty
about the domain owner's intent.   Parent-child and child-parent
authentication will be important for as long as SPF-alignment is
necessary.  For DKIM signatures, I am not convinced that relaxed alignment
should be necessary even though it has some current use because it is
allowed.

A domain owner who wants to maximize deliverability should maximize
evaluator trust in the message authentication.   Maximizing trust means
that the message should be DKIM signed, and should be signed with strict
alignment.  Our document should steer people in those directions.   The
DARA draft, which has much to contribute about the forwarding problem,
already moves us in that direction by requiring exact-match signatures.

Doug Foster