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

Scott Kitterman <> Fri, 23 November 2018 21:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B3BD127133 for <>; Fri, 23 Nov 2018 13:09: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=wIHkrKGl; dkim=pass (2048-bit key) header.b=pN/20EhF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id waqTkUjmWM8k for <>; Fri, 23 Nov 2018 13:09:51 -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 DB05912426A for <>; Fri, 23 Nov 2018 13:09:50 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201803e; t=1543007387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=6IrvBMvtR6FkeDJd/m7UWMxm0W2N+p9OgJ4nWraKaN8=; b=wIHkrKGljsbLhI807IZf6LrOsbaf4fU6TScJa7n+yhkl4/3xs71oBwLU jUVOcZ15Q6+iggyNxJvetOz4AK6uBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201803r; t=1543007387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=6IrvBMvtR6FkeDJd/m7UWMxm0W2N+p9OgJ4nWraKaN8=; b=pN/20EhF1RQoubDGB09qv6DGN3uMTT+XtZyGNhks+HjieUg40E5sXdoi azjeBdGGeg2g11flaDF9RmfQFshLE/YYAg42bcbbzMlIiquxTxqEL2eW7G aCdmtWGhklNRkWSBeBuOvay8fy92a7xAGqV9T5XVDF4pGMql7nMe4ny051 eS9CCEBFU4Jo6n6D05Iu1adUmIy+K5iopXx4GF8zd1NktUUBXzpTmhPNq7 JKckbpQZYWjtz4p2ecpN88K0lsXnlHe0dKyJVDjNb/Jj0EuRnbFLXMwoCU 50U1ctSnfVQnfzobsvKIkess2rN5gTxpOi4uJyTLIardJ/05yo3PyA==
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 0E5D4C401F4 for <>; Fri, 23 Nov 2018 15:09:47 -0600 (CST)
From: Scott Kitterman <>
Date: Fri, 23 Nov 2018 16:09:46 -0500
Message-ID: <1615692.fplaSCgD6h@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> <4277375.HHtkFxoYCE@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 21:09:53 -0000

On Friday, November 23, 2018 01:17:41 PM Alessandro Vesely wrote:
> On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
> >>> 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].
> Agreed.  Rfc7489 misses an analysis of the risk implied by feedback reports,
> except for mentioning that ruf targets receive more privacy-sensible data
> than rua's (Section 12.5).  Your I-D discourages ruf tags in PSD DMARC
> records, so that's partly addressed.
> Your I-D says some PSDs can impose a default DMARC policy while others
> cannot, but doesn't mention a rule to tell which is which.  Yes, it
> mentions a IANA registry, but then it is not clear what rules or principles
> the designated expert would consider adequate.  The case that all domain
> owners are part of a single organization with the PSO would rather seem to
> be an error of the PSL.

The problem is that there is no generic rule to cover all cases, ccTLDs, 
generic TLDs, and legacy TLDs all have different rules (and different rules 
within each of those groups).  That's why we designate an expert to figure it 
out.  Typically (as far as I can tell) RFCs that use designated experts for 
IANA registry review only give very general guidance.  The guidance here is, I 
think, appropriate (DMARC use is required for private domains registered in 
the PSD/TLD).

Arguing the PSL is wrong, isn't really helpful for this use case.  Even if the 
PSL were fixed/replaced by some dbound type thing, that would only affect the 
single use TLD case (so we delete a handful of lines from the draft).  They 
are the simplest case.

I think we should focus on the mechanism to allow for "above org level" DMARC 
checks (which is what this draft does) that is limited in scope so that 
registrars can't conduct an inappropriate land grab.  It's not like this kind 
of thing hasn't happened before [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.
> Right, the consensus is that privacy matters.  In rfc7258's words, we need
> to have a good answer to the question "Is pervasive monitoring relevant to
> this work and if so, how has it been considered?"  Unless we do the same
> for all PSDs, a good answer should also explain PSDs differences a little
> bit better than the current I-D does, which seems to be another hairy
> question.

I am open to suggestions.

Scott K