Re: [dmarc-ietf] what to document about the tree walk

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 12 July 2022 22:08 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 E334FC14F721 for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 15:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 5Jj9FBACk4Ec for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 15:08:19 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 3BF0AC14F613 for <dmarc@ietf.org>; Tue, 12 Jul 2022 15:08:19 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id r82so12272097oig.2 for <dmarc@ietf.org>; Tue, 12 Jul 2022 15:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CpIKOKNf1u/++5+sTR/39cfZ2wxZwLQ7x74BqHFI5OY=; b=P2pyKT8RDV6TPpvMaXP6CrWC5lgg0ZpgfrdqWnRrYrRqt5NAbg5Bx7R8TW7UfH+nY/ AsR71lz9v6xska2t+dOPoZVaKijYDGr2kP2+mmjyjXUvhlKL9hdzVK2eQpgWV6bui8Eu lzwEutJ7r5Rd48NkLpdJwDZbEj9CMv5dMAbAnXhYcj0PIJ8c/HoqaXpmQxZxtnM8Kvp6 UQns9L2PmZNVjCuh8VJtNbFda4NB3jp/VBbRzbiUp6Byne3tcWjilgSdbjzHLbcBpkgb tULg569XLhv4aH3i3RBhhI8uu5yj1t+HSFn5OnYredB2nQlHDo9pofm+Z0KiBfJDlinK Cssg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CpIKOKNf1u/++5+sTR/39cfZ2wxZwLQ7x74BqHFI5OY=; b=S39xKUxp1kDLyhjoLDcV+DFdg2NnvQu37NCxcBuvBVyDvAavFNUhxv3CQo1N+IC7Bd ns3qww1BYpm5HBLUtI8ulfLnbzS3jrdVDo8Rrzxvc3iO100Z0TEdxK/dLLyaNzI1039R YGPJRlUywauT9i7L7p63Eaz3e+bbeqPe43uchXhaqqA85a8JJXSDcfj6JIjG9SeoQL4X JrOV9v3fJQ94r+Clm+BnuWFKs73pC8jU2NjQNcEFR1P1x1q5j0YD+9tBUjsf9Eke4dNe Ghq/q4cCgghnFonAS6MwutYI2C4k4kGXpPZdQImNZWUlJJvTc3sGrCq8Yt3n0e3st5Kb SSrA==
X-Gm-Message-State: AJIora9Z+9MaHCUrJSTu+fhef0a+NLXfH/lf+gELyhcgJ1uqa3QyKoQ5 PmZDS7PDcu85sOdazoTkV3dNcr48KaPdB+J8Afc=
X-Google-Smtp-Source: AGRyM1va8iU8nys10WNWMc1zf/bhApDRueoOhE6fQZw80palpiqeYi7KT806DwyulLfONsC6qT4E+hgbTTxnQIbPvsk=
X-Received: by 2002:a05:6808:144b:b0:335:9d14:be9 with SMTP id x11-20020a056808144b00b003359d140be9mr3161148oiv.58.1657663698104; Tue, 12 Jul 2022 15:08:18 -0700 (PDT)
MIME-Version: 1.0
References: <20220710010547.DB3B04532F40@ary.qy> <d8716435-8a52-dac4-ede2-6c27fced7f0f@tana.it> <84DDA91C-26E2-4803-8C6C-0369ED67298F@kitterman.com> <c4a7fd03-eae8-497f-3133-73523a9c1ca2@tana.it> <5197ba5f-9de4-d838-1579-eae67683e2d4@taugh.com> <650cadee-db8f-a54a-4d14-082c2d0bed02@tana.it> <0f3a343b-e7ea-7509-ceab-e5670aac8616@taugh.com> <CAH48ZfxHgxZwu3zLh99pc1JS4s==9bxU-0nS78O=7UAnZ=DtUQ@mail.gmail.com> <CAHej_8nkpGo30b9-ZkRc_wokymJ2ry_hsMgzaB2m4EH-WWG_zw@mail.gmail.com>
In-Reply-To: <CAHej_8nkpGo30b9-ZkRc_wokymJ2ry_hsMgzaB2m4EH-WWG_zw@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 12 Jul 2022 18:08:05 -0400
Message-ID: <CAH48ZfzoVocPRKeVTqf6AE6Z48AWKFObm7X5oDa1ic1sQ5V1zg@mail.gmail.com>
To: Todd Herr <todd.herr@valimail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1f4d505e3a2e718"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/GKlxm0fjObu8y1AEelhA9CJvrn0>
Subject: Re: [dmarc-ietf] what to document about the tree walk
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: Tue, 12 Jul 2022 22:08:20 -0000

The tree walk solves the problem IF the policy has boundary information
provided by the domain owner.   Without that, aren't we substituting one
insufficiently  reliable solution for another insufficiently reliable one?

As I have said previously: errors in the PSL are expected to
org-fragmenting and therefore inconvenient, while the tree walk errors are
likely to be org-consolidating and therefore grievous.

I do not see that we have changed the risk profile favorably.  Please help.

DF


On Tue, Jul 12, 2022, 2:41 PM Todd Herr <todd.herr@valimail.com> wrote:

> On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> What problem does this tree walk solve?  Can anyone explain how this tree
>> walk improves on RFC7489 evaluation results?
>>
>>
> RFC 7489 acknowledged that its methods for discovering the organizational
> domain had shortcomings.
>
> https://datatracker.ietf.org/doc/html/rfc7489#section-3.2, which
> described the method for determining the organizational domain, one reliant
> on the PSL, included the sentence:
>
>    The process of determining a suffix is currently a heuristic one. No
>    list is guaranteed to be accurate or current.
>
> https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.6, titled
> Organizational Domain Discovery Issues, reads in part:
>
>    The DNS does not provide a method by which the "domain of record", or
>
>    the domain that was actually registered with a domain registrar, can
>
>    be determined given an arbitrary domain name. Suggestions have been
>
>    made that attempt to glean such information from SOA or NS resource
>
>    records, but these too are not fully reliable, as the partitioning of
> the
>    DNS is not always done at administrative boundaries.
>
>    When seeking domain-specific policy based on an arbitrary domain
>
>    name, one could "climb the tree", dropping labels off the left end of
>
>    the name until the root is reached or a policy is discovered, but
>
>    then one could craft a name that has a large number of nonsense
>
>    labels; this would cause a Mail Receiver to attempt a large number of
>
>    queries in search of a policy record. Sending many such messages
>    constitutes an amplified denial-of-service attack.
> The tree walk, therefore, addresses the shortcomings acknowledged in RFC
> 7489 and does so in a manner that addresses the denial-of-service attack
> possibility by limiting the DNS queries to no more than five, regardless of
> the name length.
>
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.herr@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>