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

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 26 June 2019 20:14 UTC

Return-Path: <superuser@gmail.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 2DFCF120114 for <dmarc@ietfa.amsl.com>; Wed, 26 Jun 2019 13:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UhrJWtju-4MR for <dmarc@ietfa.amsl.com>; Wed, 26 Jun 2019 13:14:19 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 7E0931200F1 for <dmarc@ietf.org>; Wed, 26 Jun 2019 13:14:18 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id 136so2446250lfa.8 for <dmarc@ietf.org>; Wed, 26 Jun 2019 13:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DXFytX3SeLWlGRTgzZ7SEiHTdUMugg9VPcR/pTVW3R8=; b=nimhew7sM3R9NgfYQWfC5zxE3aDf+FbyEt1R6D+uUFokMVXFekyvBmsm7XcIroN+Lg svXlAElhzNqx+1IqoGt90WpIfVFBcT8KHkADZe/nrQM1roxbFQ48WpC0dA4/G9e67wNm q5yDfPUOfpaiqz2mQ+KeEQbFR+VS1CCLL6DoxdFwSzauQUCiIxxj5v+VvkMnpfXUrmwn LAfX4KJtkt5IJ1NBrqpo1ZoOauwTBIbGQiL50GMPCMDit0D/qiQiT07NVpFAaJqtI4EA 4kwLnNm7legX+nfvIs9QqfXe/XoLg//jgqfk6tlLV0UQqexxAivwe1GkY4bIXbdoreSm lsCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DXFytX3SeLWlGRTgzZ7SEiHTdUMugg9VPcR/pTVW3R8=; b=rQ2VKcKDySa3ISM8WTdYzUobGXcrHBr3VADCQd00aGNqD1ZDLbOeXDf6WBs/alylQq U13W5xph4jr3pbn0nQd1NhkE7dwY/+gAhfj3fGhMz2nsg6TEjUN4iMxGcWxPh1QbVR+7 svOIOC9fAt0UHGU7xDTQjnblDMuYTXdRbtQfDIuNWGgc2TK/AZdLvyjSFyFkXd6IhgKb zXoEz5MnCIk7B+26xowjTLC4WYaxTQH0kKnezhZhwRtD7MqyxpLtQzrowbCerMPptAVL BUGZ50/OSsi9DsUpp2xjzsWKvQXLNzOauO1zqp95S4cvnTelRQDF2T6+W8KxAxTrRJ5q IOkQ==
X-Gm-Message-State: APjAAAXwtyUaBgvmq5Ek8f1Qd4NyxcJtVBZQSNDAL2e3StXoQVPmBHcX wprO6idv4Rba3mDr/2JCSa45xaLIyTKTuXBBPqp5jQ==
X-Google-Smtp-Source: APXvYqwOMWANh2v5b5MaEHW/x5RATLknUB9d/SUioF5VWjznCePxbBTbNcVaK8ywu5P5pVfnY9i3QzKh4rtE7Q5jFno=
X-Received: by 2002:ac2:546a:: with SMTP id e10mr3698554lfn.75.1561580056414; Wed, 26 Jun 2019 13:14:16 -0700 (PDT)
MIME-Version: 1.0
References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> <22952181.EZtIpUVr24@l5580>
In-Reply-To: <22952181.EZtIpUVr24@l5580>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 26 Jun 2019 13:14:04 -0700
Message-ID: <CAL0qLwY--72_AAKf6p1C-T=SHqThipWVSC7MHyOA+n8qnq6OiQ@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008d0f1e058c3fb02d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/maMcwEuKH8llSLxpuIOSUTxXzKg>
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: Wed, 26 Jun 2019 20:14:22 -0000

Just came in to start WGLC and saw this.  If you have the momentum to do an
update now (like today), feel free.  Otherwise I'll kick off WGLC shortly.

On Mon, Jun 10, 2019 at 3:26 PM Scott Kitterman <sklist@kitterman.com>;
wrote:

> 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
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>