[dmarc-ietf] Lookup Limitations For Public Suffix Domains

Scott Kitterman <sklist@kitterman.com> Wed, 21 November 2018 07:37 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 223C9127332 for <dmarc@ietfa.amsl.com>; Tue, 20 Nov 2018 23:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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, 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=o+ac2pyw; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bcWK4Cmp
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K9VlyZ_x1LIa for <dmarc@ietfa.amsl.com>; Tue, 20 Nov 2018 23:37:21 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0178A128A6E for <dmarc@ietf.org>; Tue, 20 Nov 2018 23:37:21 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542785840; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=skdp2d4wvI+xfIb40t1zqpJS3EciuiEM969huTefmtE=; b=o+ac2pyw3MGkdcNG0cZHeLWKWOGBGVruZxneDkE3ioUCskQu1Qr+60Dd aHWkIvA27gfOkgEqACoFGbv5QwJ3DA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542785840; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=skdp2d4wvI+xfIb40t1zqpJS3EciuiEM969huTefmtE=; b=bcWK4CmpI+rYhiiqc5O1VIiHU3cwPklXfTlwOW5dZxiGC7wOE+mijRqf QEFpcVu1HQxpkys+mi8xKSJsLAlSRq0ByPPEyk5RLDENa5SfobIRER6Acq vCWhWUPOmdN+WLxGFfsoyBK4xh0V2vLad7hY2jZqLFFI77RODCH0+2D1hV +clZ4HvXbutQzconM8ktZUnQaY23FADtqohEQg1tgQ2KW23lbtJNlBNtDv fw2NflkBpGt2pIsN75JUpqSfqPuCTAt0Ia0A20oHoMDrBOPNlZc0qQhvMQ nE34EeAwuXbr4FXbcEP9C6sj3Q32C/2YG9SJI6ei4G+BMz1764Jy8A==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2593FC401F4 for <dmarc@ietf.org>; Wed, 21 Nov 2018 01:37:20 -0600 (CST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 21 Nov 2018 02:37:19 -0500
Message-ID: <3881693.rR9BVk4Dlq@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lO1u-Dp8-Ya-tMApPRE1-VSIWMM>
Subject: [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: Wed, 21 Nov 2018 07:37:22 -0000

While we were discussing making draft-kitterman-dmarc-psd a working group 
item, the main discussion point was about the use of an IANA registry to 
identify participating public suffix domains.  I think it would be useful to 
consider what problems we were trying to solve and see if there are 
alternative approaches that address those requirements.

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.


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.

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 believe that if there are alternatives that support both these requirements, 
then they should be seriously considered, we just didn't think of one when 
working up the draft.

Scott K