Re: [dmarc-ietf] PSD simplification

Dave Crocker <dhc@dcrocker.net> Wed, 12 December 2018 17:38 UTC

Return-Path: <dhc@dcrocker.net>
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 1DAA7130E4F for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 09:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 snmiK1N65LzD for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 09:38:18 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59D912DDA3 for <dmarc@ietf.org>; Wed, 12 Dec 2018 09:38:17 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCHd9Gu008440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 09:39:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544636350; bh=6fxFLtdGaPPyq6MGHQrgvjlT8jrEax/SaSKvxVGSe1g=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=lRcKQTAKqzlDz/i3O8BFk8RG7XUmjeoUlPAYkqjUsvZLXEmSbf5rHYnHFXe4ddrCv hUfjMckN2EYDnMzrcujyav/VpDRRQgudfWSSku7bUY4rH9PGjdw075zqDhW4TAwnTe kHePHZZUYZm++QpjH18FrTs9Wm711wLN1mgdd12Q=
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20181212165914.36A76200B6363D@ary.qy>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net>
Date: Wed, 12 Dec 2018 09:38:10 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <20181212165914.36A76200B6363D@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fBMKXVTLj73rjvvg5u9LXgRRQkA>
Subject: Re: [dmarc-ietf] PSD simplification
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, 12 Dec 2018 17:38:20 -0000

On 12/12/2018 8:59 AM, John Levine wrote:
> In article <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> you write:
>> So I think that the functional goal of kitterman-dmarc-psd is fully
>> satisfied by merely doing a version of the 3A update to DMARC, directing
>> the client to query the immediate parent of the organizational domain,
>> if the OD has been queried and no DMARC record has been found.
> 
> Given that anything we do to handle public suffix defaults will need
> some code changes, this seems about the simplest change that would do
> the trick.
> 
> I am aware of two security or privacy issues that might come up.  If
> we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
> server can see all the queries and will have some idea of the mail
> traffic from various names.  This approach doesn't have that problem.

1. Doesn't the query to the registry suffer the same risk?

2. I'm not sure what a "DNS policy server" is.  I'm guessing it's meant 
as a DNS server that contains the dbound-ish records?

3. Given queries for MX record, don't we already have massive exposure 
of this privacy-related info in DNS activity?  How would this be so much 
more (and/or worse)?

 > The DNS operator can tell that someone is asking about a subdomain,
 > but not which subdomain.

Sorry but I don't understand this.  A bout of densitude has enveloped 
me.  Please explain, pedantically.


> The other is that the DMARC record might have rua= and ruf= and get
> detailed reports about subdomains.  This is not an unreasonable concern --
> I am the legacy registrar for various <geographic>.ny.us domains and
> my DMARC reports tell me a lot about one of my registrants who sends
> a lot of mail.  (Real mail, they're the county govermnent.)  This is
> easily addressed by clients ignoring the report advice in the OD
> parent record.

What does it mean for a /client/ to ignore the advice in the OD parent 
record?  I thought that record was for servers.


I'm now guessing that your note is primarily (or completely) about the 
basic, potential dangers of having a default DMARC record in a public 
registry, rather than being about the refinements to the PSD spec I've 
suggested?


> One issue that is not our problem but might be Scott's is that in
> ICANN contracted TLDs, they're not allowed to publish TXT records at
> _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
> permission to do so.  I happen to know the people who evaluate the
> applications (as do many other people here) and I'm sure they would
> say yes for those two TLDs, but it would involve some time and money.
> This might actually be a feature, since a similar appplication for
> _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
> scepticism.

This invites an exercise at writing a policy directive to characterize 
the types of TLDs that are good candidates for saying yes and those that 
are good candidates for saying no.  The most useful part of such a 
document would be charactizing 'types' of registries...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net