Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary?

Scott Kitterman <sklist@kitterman.com> Fri, 19 April 2019 15:44 UTC

Return-Path: <sklist@kitterman.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 C76CF120321 for <dmarc@ietfa.amsl.com>; Fri, 19 Apr 2019 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=aOD4JItk; dkim=pass (2048-bit key) header.d=kitterman.com header.b=A0sr5z9t
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 RNeniXJZpn57 for <dmarc@ietfa.amsl.com>; Fri, 19 Apr 2019 08:43:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11FE120334 for <dmarc@ietf.org>; Fri, 19 Apr 2019 08:43:58 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id AEEC3F8073D for <dmarc@ietf.org>; Fri, 19 Apr 2019 11:43:56 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555688636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aeVBIhXpaowHR+E8VwknC/3UbsH3z3x4FPuBadpHxIM=; b=aOD4JItkcWPslz+w7rPHcQ9QEsWN688CzKI2RuzFQcd0ORBV93z4xlI4 jIyebgEzQXOI/BVayJ5PWoopfx8oDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555688636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aeVBIhXpaowHR+E8VwknC/3UbsH3z3x4FPuBadpHxIM=; b=A0sr5z9tKYel8WwJRQczBuiXiynfQT8biYmyx/zZl5m6OreJur4hq7u4 EEvzXTk8gaQ7xLVQY3rw6E4olUBld+9c9sDKzjzfvMejQnJiJbzc+/aYv5 HvQjz9kIvg+tdVVFH+4ukDn+cGCBRbGDE42fn5Tgjl5GcBoxU6hohFBmNl rdZjukux+f/BVBKZsZyx2/sXuWKtgwKlyFE2jFuN/N4bzhVb7kSIdag077 3bWrYNNiueSOh+9faYSQalXSdYbzRxFkGpalw9+pe6oSvgYFb/z1bAI3kX Lq9VdINMK9F4UvzFD30PmWAYYcfD1RvK1t0qQuJISHD/KsJuDx8rxQ==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 73D8AF801E7 for <dmarc@ietf.org>; Fri, 19 Apr 2019 11:43:56 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Fri, 19 Apr 2019 11:43:51 -0400
Message-ID: <1897481.12dR8pik7S@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-168-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CABuGu1qEbPGed+abDH8Ps06+4L=hQn+9QrbZc9EDsWmoQHWVsg@mail.gmail.com>
References: <CABuGu1qEbPGed+abDH8Ps06+4L=hQn+9QrbZc9EDsWmoQHWVsg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/A68APDfeP2JohwClYFJK87iV880>
Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary?
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: Fri, 19 Apr 2019 15:44:05 -0000

On Thursday, April 18, 2019 12:45:42 PM Kurt Andersen wrote:
> If we have a boundary that is 6 names deep in the DNS hierarchy (so the org
> domain would be 7 names long), then what is a DMARC validator supposed to
> do with an email that claims to come from the domain that is only 5 names
> long? What happens to the second lookup (org-level)?
> 
> Example:
> 
> priv-org.psd-a.b.c.d.e.example: If an email comes from
> sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-a.b.c.d.e.example, then
> lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.priv-org... and the
> proposed lookup 3 (for PSD protection) would be _dmarc.psd-a...
> 
> If the email comes from b.c.d.e.example, then lookup 1 is _dmarc.b... but
> what would lookups 2 and 3 be? skipped?
> 
> --Kurt

It's an interesting question, since I think may be a hole in DMARC generally, 
but we can fill it, if needed.

I took a look at the non-comment content of the public portion of the PSL to 
get an idea of the scope of this problem.  Here's the distribution of lengths 
of public suffixes:

one: 3077
two: 3821
three: 1986
four: 3

None longer than that, unless I screwed up my script.

Since more than 20% of the currently documented public suffixes are longer 
than two dots, I think this is a use case worth covering, but I don't think 
changes are needed.  In every case I checked, if c.d.e.example is in the PSL, 
then d.e.example, e.example, and example are also listed, so the proposed PSD 
DMARC lookups should succeed just fine in these cases.

The privacy implications of these types of public suffixes are no different 
than the longest public suffix, since we don't know that they are not also 
used for registering non-public organizational domains.

It might be useful to state this as a condition required for PSD DMARC to work 
correctly, so it's documented rather than just a happy coincidence of the 
current PSL implementation.

Scott K