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

Scott Kitterman <sklist@kitterman.com> Mon, 10 June 2019 22:26 UTC

Return-Path: <sklist@kitterman.com>
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 1AA7112006E for <dmarc@ietfa.amsl.com>; Mon, 10 Jun 2019 15:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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=ebIGibBt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=QAeLOGM9
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 NEnPI7GVIHmb for <dmarc@ietfa.amsl.com>; Mon, 10 Jun 2019 15:26:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF2A120025 for <dmarc@ietf.org>; Mon, 10 Jun 2019 15:26:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id A6355F807AB for <dmarc@ietf.org>; Mon, 10 Jun 2019 18:26:13 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1560205573; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=w/MNzqVlc2DfyU+8CFSNlveb1mrqXlRefxQiII2J4jc=; b=ebIGibBt8aWxYvNOKdk3wcAhe3fxUw+dtcQSifvCK6eddaianNJuLa/F HfFi2HRc50M1ThKn6PHInAJ0HjKABw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1560205573; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=w/MNzqVlc2DfyU+8CFSNlveb1mrqXlRefxQiII2J4jc=; b=QAeLOGM92vWF/vWOveEy7N8KXne15dbFHzyHt6VX0DROu3G7X20cAxm3 B20Zbau513a+jNv8qwTFO2qe/M5e2sf+cWkX0aF3BPcwUWRz5c19iErFae 6toWWcQzW9Gm5OLAo1+smKLjcffCo7ekcHKsQ4hcV/eaK47EPEWh+ZN1jr h3rgtP1Xw7uuaiHIQfMgwPzlvP5M+sv+PwPxx1Mp8SwXITzcfLoe6U05Rl FB3z5gZHcNGTF44n/771B3SEx+de0+c9uogxuSdvIlnPolIewIlD0TxYut Bg5QWK5S2XRRQao9QgfIVda+Ci3nTI9l8Pqdq9et3Msd24YtFDq2fg==
Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 6E58AF8001B for <dmarc@ietf.org>; Mon, 10 Jun 2019 18:26:13 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Mon, 10 Jun 2019 18:26:12 -0400
Message-ID: <22952181.EZtIpUVr24@l5580>
In-Reply-To: <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net>
References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/qgru5AZU59XeQjMZuB3Ei7S9ujw>
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: Mon, 10 Jun 2019 22:26:17 -0000

On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote:
> > 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.

Thanks.  I think those are all good comments.  I can crank out an update or 
wait until after WGLC as the chairs prefer.

Scott K