Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

Doug Foster <fosterd@bayviewphysicians.com> Tue, 24 November 2020 18:49 UTC

Return-Path: <btv1==597e9c9d5ab==fosterd@bayviewphysicians.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 38BF43A13AE for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 10:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWaenedpLSzf for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 10:49:36 -0800 (PST)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264F63A13AC for <dmarc@ietf.org>; Tue, 24 Nov 2020 10:49:36 -0800 (PST)
X-ASG-Debug-ID: 1606243774-11fa313c014de90001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id klQHJcorM3HUswNQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 24 Nov 2020 13:49:34 -0500 (EST)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=DHTDMSCKnKqk1eX+FEo5ZvonRUItifKX9OpXcUae7bU=; b=M7O0lpdHr/2eViUN7AbBMr56WiO4DJ0t5iZPa+tjwB65kt+VyxuQO0BjNakhdu6GF EXgIVuxZqmoqBwx2TIRRdLfTRruIsuAg364KixwwRTvYzd+oSzSn/hdMwkz1kodP1 TtLkKQzDeTtqxHQkwoER72QUFWTwwFhSHiJj/Hk7Y=
Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 24 Nov 2020 13:49:26 -0500
From: "Doug Foster" <fosterd@bayviewphysicians.com>
X-Barracuda-RBL-IP: 192.168.2.194
To: "'Dave Crocker'" <dcrocker@gmail.com>, <dmarc@ietf.org>
References: <20201124172142.3721027E0851@ary.qy> <6e5a3818-651a-6ae7-9639-3380ef2c111d@gmail.com>
In-Reply-To: <6e5a3818-651a-6ae7-9639-3380ef2c111d@gmail.com>
Date: Tue, 24 Nov 2020 13:49:26 -0500
X-ASG-Orig-Subj: RE: [dmarc-ietf] Doing a tree walk rather than PSL lookup
Message-ID: <001601d6c292$88a189b0$99e49d10$@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D6C268.9FCC9320"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKk2KKCq/FP3JYUwX5q4FLoKNwVTwN9iY3TqB+HDpA=
Content-Language: en-us
X-Exim-Id: 001601d6c292$88a189b0$99e49d10$
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1606243774
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Barracuda-BRTS-Status: 1
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 9514
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-d3Ft8F1eXf9pRAiVhljm1vCwW0>
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Nov 2020 18:49:38 -0000

Better a correct answer slowly than an incorrect answer quickly.

 

For the existing PSL, it is not just the accuracy of the document itself, but also the accuracy of the parsing process.   Is there a well-trusted parser floating around?

 

DF

 

From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker
Sent: Tuesday, November 24, 2020 1:19 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

 

On 11/24/2020 9:21 AM, John Levine wrote:

With the tree walk, I was thinking that if the tree walk finds a _dmarc record, that acts
as the organizational domain, so finance.acme.example can only allow alignment with itself
or its descendants.
 
This is different from the way that OD works now, but the questions are is it worse, and what
will break if we do it.

 

Let's consider some attributes, starting with a trivial initial set...

 

Accuracy:       How accurate is the data that gets retrieved?

Reliability:    How likely is it that a query will complete successfully?

Latency:        How long does it take for a query to complete?

Vulnerability:  How easily/likely is it that the service can be compromised?

Scaling:        How well does it operate, at Internet scale?

 

                   PSL                      Tree-Walk

Accuracy:          Known problematic        100%

Reliability:       High                     Mixed

Latency:           None                     Potentially high

Vulnerability:     Generally none           DOS

Scaling:           Poor admin, good ops     Good admin, potentially poor ops

 

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org