[dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04
"Kurt Andersen (b)" <kboth@drkurt.com> Fri, 12 July 2019 22:35 UTC
Return-Path: <kurta@drkurt.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 5EBF7120112 for <dmarc@ietfa.amsl.com>; Fri, 12 Jul 2019 15:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 LSrpLG_F7hO3 for <dmarc@ietfa.amsl.com>; Fri, 12 Jul 2019 15:35:47 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 24B2E12009E for <dmarc@ietf.org>; Fri, 12 Jul 2019 15:35:46 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id j5so19576904ioj.8 for <dmarc@ietf.org>; Fri, 12 Jul 2019 15:35:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=Fa396jQHfS5kTG9fbWkiJV7cBHwN6sqayh3VeLNL8Qw=; b=GHkpQoF/GObO/QUNyEYiEB4AakKg/ystLFQ/5/V0sPUf27MX/3IWxZAj0fYfx9c9JZ Vmm4GgThO7FnChRCzsAnU8iWjvqhVr1UsehGLmOjd3rrQxPS5gyQVwgw9P0vhb3cQ4Ba qhpE7KtrWv7hQ51BTf/aYdQEkQaPA6YWoSZNg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Fa396jQHfS5kTG9fbWkiJV7cBHwN6sqayh3VeLNL8Qw=; b=T9j7dLtCeVhdp6qyH8DL64vrdx7jJ0oiC2/geEUHXMSexYEG3Ab8r3Emu5MMvVUV6N J6aumuRE4nObfsmyrLHS5w190CCg7NRcpbjoq9q+3GFgEGrdwQvPMCC8IAP6sq5CPS3U Vs1F0Wg65ntDJx713bVF6mluSAm77IN4lnuHjjfJsq2TzaagTNX8vnQaCSDSuzD6i3mQ xB5kFM5WrW0JEcSz+GfliX8GRy4LQc9t0IqCA1ycsCgMW/8cXwMmhiZnv6Q57okVTx4A 2tdeQb7bnVD+SfPKerpMeHMVoKxrPPVC3ifSQuWAzub94r8M9K5jTbdxMOidFqIuhti1 1+ng==
X-Gm-Message-State: APjAAAUOPnXn8FdMc/4soix3u4u2czV70Y0MrGF/uEhWX5Zx1oN+vi9r z/DZHzrpgYfCRCfGYhyM7Hwpgvb+1Xh2DR+An0Wze/NGiBw=
X-Google-Smtp-Source: APXvYqz3kHz8WuCBZmKsecRmz2QVbIwkPrZSQLR9IPQI6BctFgooL/XKusQQJd+xru+d2/MQj69YwtMxHJHRLBXC7Yo=
X-Received: by 2002:a02:9004:: with SMTP id w4mr14501034jaf.111.1562970944904; Fri, 12 Jul 2019 15:35:44 -0700 (PDT)
MIME-Version: 1.0
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Fri, 12 Jul 2019 15:35:31 -0700
Message-ID: <CABuGu1rXk93fp_BD18Zc8RAP9d6PcUvgzDX09xGAssXnSAWM-g@mail.gmail.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f73989058d838717"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/7Qjo6oEoUpPGvCWVFZHyBeCDI44>
Subject: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04
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: Fri, 12 Jul 2019 22:35:49 -0000
Please note that I did not review Tim's comments in detail so some of the following points may have been covered by him previously. *Page 2 contains the following paragraph:* This memo provides a simple extension to DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>] to allow operators of Public Suffix Domains (PSDs) to express policy for groups of subdomains, extends the DMARC [RFC7489 <https://tools.ietf.org/html/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. This extension does not really allow PSDs to express policy for "groups of subdomains" unless you take the perspective that "all or none" are groups. Perhaps altering the language to say "...to express policy that would apply to subdomains..."? *The very end of section 1 says:* DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>], by design, does not support usage by PSOs. For PSDs that require use of DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>], an extension of DMARC reporting and enforcement capability is needed for PSO to effectively manage and monitor implementation of PSD requirements. I still fail to see how this proposal is necessary (or, potentially even useful) for the PSO to perform enforcement of their policies. I'd recommend either deleting the entire paragraph or refocusing the second sentence around the brand protective role that this proposal brings for abuse of non-existent subdomains below the PSD. *Section 2.2* "PSD DMARC includes all public domains..." --> suggest "PSD DMARC applies to all public domains..." *Section 2.6* "...that a receiver is willing to accept" seems like it opens up a wide area if one applies considerations like DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this topic so I'll defer to that thread. *Section 3* should include the new "np" keyword as an update to the DMARC spec. *Section 3.5* This call-out makes it seem like information about non-existent domains is not desirable and useful for org-level DMARC. Can we modify the language to remove that implication? Perhaps "...is desirable and useful, just as it is for org-level DMARC operators." *Section 4* Neglects the privacy implications of broken "receiver is willing to accept" conditions that may lead to additional leakage. Also in the third bullet point, "it's feedback" should not have an apostrophe. --Kurt
- [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-… Kurt Andersen (b)
- Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-… Scott Kitterman
- Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-… Scott Kitterman