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

Alessandro Vesely <> Fri, 23 November 2018 12:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68179128B14 for <>; Fri, 23 Nov 2018 04:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0tNx2OoM8Kg3 for <>; Fri, 23 Nov 2018 04:17:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 756D0124D68 for <>; Fri, 23 Nov 2018 04:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; t=1542975461; bh=0MPIFL6/eSSnQtrLnYdrNIIvCyTXRZ0DJX4tLeK+Vm0=; l=3854; h=To:References:From:Date:In-Reply-To; b=CASbpqpiYXS6jNNQytStGhRalAAFPZjOXqPYMRQmF07s3htWYxMB3COWQYnU5vIKk NiT3CNB1xA0AjLByvJguG9zEZy7lkR8Hp1hEag3M6tH2Vj3bUxqolnNlp49wWgAidM 99OSOXyK/OsqmexcUMvo0rzASbWGrBCMcFxbzLqi2NHIY37TiKr5Kf7XpzRRj
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Fri, 23 Nov 2018 13:17:41 +0100 id 00000000005DC013.000000005BF7EFE5.00001F97
References: <3881693.rR9BVk4Dlq@kitterma-e6430> <> <4277375.HHtkFxoYCE@kitterma-e6430>
From: Alessandro Vesely <>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Autocrypt:; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bub
Message-ID: <>
Date: Fri, 23 Nov 2018 13:17:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <4277375.HHtkFxoYCE@kitterma-e6430>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 12:17:46 -0000

On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
> [...]  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.

That sounds acceptable to me.  I don't think one extra query is going to have a
tremendous impact:

DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since that
is required for sending aggregate reports.  The availability of such a database
makes it handy to store parsed policies as well.  That is to say, a well
designed mail filter can cache DNS data directly.  Hence, given a decent SOA
TTL, that extra lookup can probably be skipped on most messages.  Compared to
the amount of per-message DNS queries, it doesn't seem to hurt.

DMARC could have a better say on implied TTLs, since data seen at lookup time
is going to be reported at end-of-day time.

> 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.

Neither do I.

>> [*]
> I'm not sure why you even mention this since the draft proposes no new DNS 
> functionality.

I had read about instructive re-readings of DBOUND in previous discussions on
this subject, so it seemed worth to consider the camel load.

>>> 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.

> 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.