Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt

Tim Draegen <tim@eudaemon.net> Tue, 04 June 2019 22:37 UTC

Return-Path: <tim@eudaemon.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 56FCF12003F for <dmarc@ietfa.amsl.com>; Tue, 4 Jun 2019 15:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.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 ZeFLeJ5n0QGF for <dmarc@ietfa.amsl.com>; Tue, 4 Jun 2019 15:37:50 -0700 (PDT)
Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC78E120242 for <dmarc@ietf.org>; Tue, 4 Jun 2019 15:37:49 -0700 (PDT)
Received: by mail-yw1-xc2a.google.com with SMTP id b143so965150ywb.7 for <dmarc@ietf.org>; Tue, 04 Jun 2019 15:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=WcfXbBet/e6LOYIMkT1ytNkEx82NK3WwkInIaSjSGQ0=; b=O3tlB108/OiDh7qsKt4PTGA2i9OmKr3hNW0wLBeHMReSDzofynE21nnqjhSdAWUy70 hilZTqeEJcFWmOHDGza0lW6ECWZartZh0Mo6kdgQOobd2CEBlw7GVfUcu080RFfFqMkz uKQ2ZrnVw0mC5XLFP03Tl0eA81AU/U5M2adKk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=WcfXbBet/e6LOYIMkT1ytNkEx82NK3WwkInIaSjSGQ0=; b=NptgOoEmcN9vjUY4G0LKEr5hniPkY1cKW5BTYW3Mu8+h/TEh90SxuV4KV5xo5dOlsW VhAFXiRMfAvq21vPI+ZyPb/xZodDpzVcCKUv5UJ6rcaTQcvqKUkMziLqHTSzygKmz70N JHSRXx+x9rgBQcUNH/grfpmqS+YFwtL2XE6MoYtrxoDdZJdbH4uIBBMc9r1JsTWCEyxA roncy6s0zr0MBvoDx//uqlTF1MlUJr6OIzrNkoyHRLs+njX0pKqdUpRAQ7DiKetf8V8D UQG7JoCzp/B2Sd1xUJyDsn9+graUsxbzRH+w3CNtF2YfcHQtcCYU6hJ20pzCTzsBnVjw EZcQ==
X-Gm-Message-State: APjAAAVRuYaKBWctV3pJxsRYiofpUBL7aTnoSpYer4sAk4HCngRNNRhM O4tOLC08HqdfhUkTN+xAtQHTIEyriuk=
X-Google-Smtp-Source: APXvYqzoG6W3ObdlkDQnwzCfh9M2iNVFJ7CRpDUIFqou2X1hbolnAk34bNa2DpkSwnuQumHqoysiVw==
X-Received: by 2002:a81:3250:: with SMTP id y77mr7765148ywy.437.1559687868625; Tue, 04 Jun 2019 15:37:48 -0700 (PDT)
Received: from [192.168.203.118] ([68.235.232.199]) by smtp.gmail.com with ESMTPSA id b132sm5046163ywb.87.2019.06.04.15.37.47 for <dmarc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 15:37:48 -0700 (PDT)
From: Tim Draegen <tim@eudaemon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 4 Jun 2019 18:37:47 -0400
References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <2350589.KE7Alnpban@l5580>
Message-Id: <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/e7aDFcxDdJPI2Sj4jMqGLmDhmKc>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt
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: Tue, 04 Jun 2019 22:37:53 -0000

> On May 27, 2019, at 6:59 PM, Scott Kitterman <sklist@kitterman.com>; wrote:
> 
> On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Domain-based Message
>> Authentication, Reporting & Conformance WG of the IETF.
>> 
>>        Title           : DMARC (Domain-based Message Authentication,
>> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
>> Author          : Scott Kitterman
>> 	Filename        : draft-ietf-dmarc-psd-04.txt
>> 	Pages           : 11
>> 	Date            : 2019-05-27
> 
> There isn't much to this update.  It corrects one typo and reverts the RUF 
> MUST NOT as discussed on the list.  As far as I'm aware there are no other 
> pending issues in the WG with the draft.

Hi Scott, I've reviewed the doc and have made some comments. Feel free to dispose of them as you will.

I had a hard time with the introduction. "sets of domains within a single organization" and "lower level policy" left me not knowing what I was reading. I'm unhappy just complaining, so I took a stab at this admittedly difficult section. The original:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and sets of domains
   within a single organization.  For domains above the organizational
   level in the DNS tree, policy can only be published for the exact
   domain.  There is no method available to such domains to express
   lower level policy or receive feedback reporting for sets of domains.
   This prevents policy application to non-existent domains and
   identification of domain abuse in email, which can be important for
   brand and consumer protection.

My stab:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and for organizational
   domains and their sub-domains
   within a single organization.  For TLDs and domains that exist between
   TLDs and organization level domains, policy can only be published for the exact
   domain.  No method is available for such domains to express
   policy or receive feedback reporting for sub-domains.
   This missing method allows for the abuse of non-existent organizational-level
   domains and prevents identification of domain abuse in email.


The example section doesn't read like the rest of the draft and was hard for me to read through. Original:

   This would provide policy and feedback for mail sent from
   @gov.example, but not @tax.gov.example and there is no way to publish
   an organizational level policy that would do so.  While, in theory,
   receivers could reject mail from non-existent domains, not all
   receivers do so.  Non-existence of the sending domain can be a factor
   in a mail delivery decision, but is not generally treated as
   definitive on its own.

Again my stab:

   This DMARC record provides policy and a reporting destination for mail sent from
   @gov.example. However, due to DMARC's current method of discovering and applying
   policy at the organizational domain level, the non-existent organizational domain of @tax.gov.example
   does not and cannot fall under a DMARC policy.


I don't have too much more, I just got just caught up in the initial read. This paragraph contains a construct that was confusing to me:

   This memo provides a simple extension to DMARC [RFC7489] to allow
   operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489] policy query
   functionality to detect and process such a policy, describes receiver
   feedback for such policies, and provides controls to mitigate
   potential privacy considerations associated with this extension.

^^^ why "groups of subdomains" and not just "subdomains"? One step further, why not "express policy at the level of the PSD that covers all organizational domains that do not explicitly publish DMARC records"?


OK, two more things:

2.3.  Longest PSD

   Organizational Domain (DMARC [RFC7489] Section 3.2) with one label
   removed.

^^^ "one left-most label removed"?


Last thing: Security considerations might call out DNS cache poisoning as a way to get reports for a PSD. Applies to vanilla DMARC too, but the scope and potential breadth of information with PSD-DMARC is really interesting. I imagine an attack that gets .COM listed into the PSD Registry for a specific report generator.. combined with cache poisoning and the poor report generator would probably explode at best.