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

Todd Herr <todd.herr@valimail.com> Tue, 12 July 2022 18:41 UTC

Return-Path: <todd.herr@valimail.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 01DFCC14CF1E for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 11:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, 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, 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=valimail.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 zfnz-I8sqskZ for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 11:41:07 -0700 (PDT)
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (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 550F3C14F6EB for <dmarc@ietf.org>; Tue, 12 Jul 2022 11:41:07 -0700 (PDT)
Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-31cf1adbf92so90530497b3.4 for <dmarc@ietf.org>; Tue, 12 Jul 2022 11:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFisk+FuILftWT3wGSpcShnSt2BXuh2VAUSve036ueQ=; b=E2ORCYSenoLqYdVBE+xkJL3syuXMbbJm9sw7BOb1J6Tc9kYlx85OvdiO2pK5ohplqo 4Dtbk65vNxtzP6bkLyjmj6tx1avwpyypfNwGwmSonpT1MjoSzmyQizyUbvmbrPv4tqP5 PuUyh6FCfXxxYv3k9p5PrHgZjvXpsSY8Cv24tbrGulsOvhzh87QTmjqfIlJG+SATRPUG 0J/dfwHau3lOY9WSLMiarKGW9ItJ1an9aER6qeccBXm12Y8Xoor3avPKMGSQNEHxm/Zz g/8fgoaz7vdN8/uZRe+JKLHXI7+9l/dznbGghG1AgGzPh2dYa5eZSaSJzyKCOfvxxENf 6Q8Q==
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=tFisk+FuILftWT3wGSpcShnSt2BXuh2VAUSve036ueQ=; b=p7Y3Lu0+Gs3m6ofe0NKkM2TFHeNcurCXR0fit7CSOE3H3gPOeVedwJkA1VUk9zBXRR lUE5qx3FYG5nhXeJ0DO/iAJVfU8iUnpfLPK7ddsAdHCSxum5BgSQYNzBG/R0cjvHG+BI hVqn0Ydq76Y9XMMnSf1+kb8DDZbx3mabECqZVzOVhTfnprhk9fXjrhBpMxzSyL+xSslW XLd2sNnA3mC1dyr0zL2A/upzUPPvA04ivGtePdGy8iHzFt8hPNPjYoD+n7WOnMdzlEHH wiTDYSpqPVOtu+QAs47CUnSd0zwWBHzqUsrX/xZmyzcEyWAsKlLLfwlvH1mTa3SpQ6fa 8Vhg==
X-Gm-Message-State: AJIora/myrRGAf5XYAJTWZkln1wtVtwbIJyV5T8S/87BvCYfmrtbRjXw rvvArjXg8M9aVQtQPku1+RgzW42nVNkFIzN8UZbH+GFkwmhorQ==
X-Google-Smtp-Source: AGRyM1skSWd6dXXEYhdq0ovfaQuT3EBYwwi6EshhCAu/cdazy2rk6GTfb7IKHssdqEmEe9No4/DtIWuK6MytroqeuLY=
X-Received: by 2002:a81:7958:0:b0:31c:9ec6:9889 with SMTP id u85-20020a817958000000b0031c9ec69889mr27020233ywc.398.1657651266059; Tue, 12 Jul 2022 11:41:06 -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>
In-Reply-To: <CAH48ZfxHgxZwu3zLh99pc1JS4s==9bxU-0nS78O=7UAnZ=DtUQ@mail.gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 12 Jul 2022 14:40:50 -0400
Message-ID: <CAHej_8nkpGo30b9-ZkRc_wokymJ2ry_hsMgzaB2m4EH-WWG_zw@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0134805e3a0023f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/__NjNoe1Tp72TIiCXIWt8cWExks>
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 18:41:11 -0000

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.