Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

Scott Kitterman <> Fri, 23 November 2018 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C317124BAA for <>; Thu, 22 Nov 2018 23:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=7jNGKbe4; dkim=pass (2048-bit key) header.b=GFxFSw28
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q6BiSRRLCwhR for <>; Thu, 22 Nov 2018 23:20:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C80A61286E3 for <>; Thu, 22 Nov 2018 23:20:49 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201803e; t=1542957648; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ulcC8iZ/Sev76uWNq5+FY8+B1EqGsskmHUPT317K+p4=; b=7jNGKbe4hokJu9eJ9fze16TX8WvoTDBOciLXu/jHOsOCjoMVe32Cli2o Jc3+JdxY7mXEOIPk1PEEtDYHwGSjDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201803r; t=1542957648; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ulcC8iZ/Sev76uWNq5+FY8+B1EqGsskmHUPT317K+p4=; b=GFxFSw28zJ7+pGfISKpsuXLBh1BWtiQPjrIZAbxBM3y8dJCfk2TQbebh T1VO48dGBzafhAUiGiALluc5v19URCCTqnJ1AGfHcucq62Yfe7b5WuOXgF LvXD1MGfQb5apUaaJ00QxNZgx0/UGwQZ0krBJH99KH6hRWl/hXAqTG2CqA U229EMME9KlY3dPWZyIreGo97Tf3Q9rHeFgNLrcoy1MWF4/tnuirFTO76M 5BAC0VTDDq0JUhhfXiI8blcl84OlCVQ+ijF7q9yAtRRsNpjCLOU8EnnxSd wy56MrhDB6jDidNUsOSfAtqyfXI//rinoNiCPGbDNtXqaMbkxXkGLA==
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4EAA5C40198 for <>; Fri, 23 Nov 2018 01:20:48 -0600 (CST)
From: Scott Kitterman <>
Date: Fri, 23 Nov 2018 02:20:50 -0500
Message-ID: <4277375.HHtkFxoYCE@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <>
References: <3881693.rR9BVk4Dlq@kitterma-e6430> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Nov 2018 07:20:53 -0000

On Thursday, November 22, 2018 06:20:52 PM Alessandro Vesely wrote:
> On Wed 21/Nov/2018 08:37:19 +0100 Scott Kitterman wrote:
> > [...]
> > Also, while I think the discussion about a DMARC specific public boundary
> > discovery mechanism was useful, and we should consider taking on that
> > work, I think it's not closely coupled to Public Suffix Domains and
> > should be discussed as a separate work item.
> /DMARC specific public boundary discovery/ is still ambiguous.  Given the
> nature of the I-D, we are splitting the concept of boundary into two types:
> 1. *Alignment* which defines sets of shared responsibility, and
> 2. *Policing and reporting* which defines sets of shared criteria.
> Type #1 is a refinement of #2.  For example, all banks may wish to share a
> secure policy and possibly a common surveillance method.  However, they
> don't necessarily share customer accounts (let me recall that sharing
> session cookies implies just that.)

I'd suggest having the argument about if PSL is good enough or if we need a 
mechanism in DNS in a separate thread (which is why I wrote another mail to 
discuss that very topic).  There's nothing in this draft about defining where 
the boundary is (just as in DMARC itself).

> > Goals:
> > 
> > 1.  Minimize additional verifier burden for adding PSD DMARC support.
> > Currently it requires consulting a locally stored, infrequently changing
> > list and one additional DNS lookup only for participating public suffixes
> > when there is no organizational domain DMARC record.
> Browsing a copy of the PSL, I found just 17 entries with 5 labels, like:
> and
> Querying each subdomain would require 4 extra lookups.  How much do we save
> in a dbound-like scenario?  What about organizations that have not yet
> published boundary information?  How about the camel[*]?

No.  There's nothing in the draft about walking up a tree.  The draft looks 
one label higher in the tree than the organizational domain, that's it.  One 
and only one is the maximum additional number of lookups in the current draft.

I've no idea how a DNS indication of the boundary would help or hurt these 
cases, but it's orthogonal to the subject of this message.

> [*]

I'm not sure why you even mention this since the draft proposes no new DNS 

> > 2.  Externalize signaling about PSD participation.  As discussed in the
> > Privacy Considerations (section 4.1), we were concerned about the privacy
> > implications of feedback on organizational domain traffic for
> > organizational domains that don't participate in DMARC being
> > inappropriately captured by public suffix operators.  In order to avoid
> > this, we identified criteria for which public suffixes PSD DMARC would be
> > appropriate for and require an external review to ensure those criteria
> > are met.  No solution that's in DNS will address this part of the
> > problem.
> I'm not clear what kind of inappropriateness is implied here.  The
> overwhelming majority of people is pretty comfortable with having their
> personal stuff stored in "Echelon".  Yet, if a domain is uncomfortable with
> the policy in, it can opt out by publishing its own record.

That's exactly backwards and the reason I wrote the privacy considerations.  
It's also completely contrary to IETF policy on the subject, see RFC 7258/BCP 
188 [1].

During the adoption discussions there was some concern with the registry 
approach used so far.  I would really like to have a discussion on 
alternatives.  Personally, I don't think it's very useful to spend working 
group time on if privacy matters.

Scott K