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

Alessandro Vesely <vesely@tana.it> Thu, 22 November 2018 17:20 UTC

Return-Path: <vesely@tana.it>
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 AA102130F47 for <dmarc@ietfa.amsl.com>; Thu, 22 Nov 2018 09:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 8hhbo7pcPrng for <dmarc@ietfa.amsl.com>; Thu, 22 Nov 2018 09:20:55 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE3912E036 for <dmarc@ietf.org>; Thu, 22 Nov 2018 09:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1542907252; bh=OAh77NrStRPfMFRhhOV4lDqFTTjlXIC2H24xHWUfvDE=; l=2480; h=To:References:From:Date:In-Reply-To; b=Ca0F13SxDAlY77FWeuwvnEHiWSuSdoXYvO70nodCxXL6V8AjZa+7eP+DsKFYSv/eF g1oWrx88RCJ4QsKCRmLJ4kqGjnu6P9w6CGH2FRy8e3bbvDHmJ58eZ+G5MXiLpW0Fan Xlxj4o9Qf8aQZfV1qOxAfXSgTlQ699s60hJYmxe/TNjUCE54QYPYT5D+yJ47u
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 22 Nov 2018 18:20:52 +0100 id 00000000005DC013.000000005BF6E574.00000544
To: dmarc@ietf.org
References: <3881693.rR9BVk4Dlq@kitterma-e6430>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Autocrypt: addr=vesely@tana.it; 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: <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it>
Date: Thu, 22 Nov 2018 18:20:52 +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: <3881693.rR9BVk4Dlq@kitterma-e6430>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/53NtAJobTkPPlOHCJ2yefmV2OpA>
Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
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: Thu, 22 Nov 2018 17:20:58 -0000

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


> 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:
s3.cn-north-1.amazonaws.com.cn and
app.os.stg.fedoraproject.org

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[*]?

[*] https://ietf.org/blog/herding-dns-camel/


> 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
_dmarc.com, it can opt out by publishing its own record.


Best
Ale
--