Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04

Scott Kitterman <sklist@kitterman.com> Fri, 26 July 2019 20:27 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 89DA6120071 for <dmarc@ietfa.amsl.com>; Fri, 26 Jul 2019 13:27:39 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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=PvQ+2q3t; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XfgCtsVb
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 7zlcE0uPW5wz for <dmarc@ietfa.amsl.com>; Fri, 26 Jul 2019 13:27:37 -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 75A18120047 for <dmarc@ietf.org>; Fri, 26 Jul 2019 13:27:37 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 5B83DF80758 for <dmarc@ietf.org>; Fri, 26 Jul 2019 16:27:36 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=PvQ+2q3t7C6FCFVmuWOUFpYkoPNTOITVCV0J4D2PkpI6KtwzTrUu/mcm IgjJng9jSzmVPMT0x/TEHyvwWKI4Bw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=XfgCtsVbVs1jj5ircyjv8+XHE8Umgs7Aut7ouNMeyGnvk7OayFqcm0Yk RZsFp6Q3MsFKuydIOTcTze18LveA8fRCgZD+DET37HrAi5H+WPE+jACckY 7AZcmGAsIdZcT2HzjukOhXSyKswRoWs5Vp3Txvw0q46YlcNGuGMh5boK0N tiiURG5OeTw2D2xgdjjGY7pKtpPWR151KmtPJygHmE3rjwDrJsvZ6w0yj4 tb0Q8il5ZfU/5uyhIrB+1AmZ5fDJl10g/2yVvLX+NZbg5mYIVoTY+I8Z69 BpzJ9XinqYTyk41n85k8y2g5XbX0hqml32k1XaW6c96wfxhA6MxHCw==
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 29279F80096 for <dmarc@ietf.org>; Fri, 26 Jul 2019 16:27:36 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Fri, 26 Jul 2019 16:27:35 -0400
Message-ID: <2236077.6bFe0TRX2e@l5580>
In-Reply-To: <CABuGu1rXk93fp_BD18Zc8RAP9d6PcUvgzDX09xGAssXnSAWM-g@mail.gmail.com>
References: <CABuGu1rXk93fp_BD18Zc8RAP9d6PcUvgzDX09xGAssXnSAWM-g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8BACqpTta_ndXeivvRK-rjI2hm4>
Subject: Re: [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, 26 Jul 2019 20:27:40 -0000

On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote:
> 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..."?

I think the changes I just pushed in response to Tim's comments address this.

> *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.

Agreed.  Deleted.

> *Section 2.2* "PSD DMARC includes all public domains..." --> suggest
> "PSD DMARC applies to all public domains..."

Incorporated.

> *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.

This went away due to that discussion.

> *Section 3* should include the new "np" keyword as an update to the DMARC
> spec.

Added based on the no existent domain sub-thread.

> *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."

Incorporated.

> *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.

OBE, related text is removed.  Typo got fixed somewhere along the way.

Thanks,

Scott K