Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02

Scott Kitterman <sklist@kitterman.com> Fri, 12 April 2019 16:13 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 4A4C5120887 for <dmarc@ietfa.amsl.com>; Fri, 12 Apr 2019 09:13:58 -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=xXZaZ1sK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XKMkKi1d
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 aUt-cGFjMghc for <dmarc@ietfa.amsl.com>; Fri, 12 Apr 2019 09:13:56 -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 0A32A12085C for <dmarc@ietf.org>; Fri, 12 Apr 2019 09:13:56 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 02811F807C6 for <dmarc@ietf.org>; Fri, 12 Apr 2019 12:13:55 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555085634; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hVnledz5uT+xLmBb4lxzteBXSEhZ/0ivhBAAtHo8eJU=; b=xXZaZ1sKu0EfxxRjC9gzhyQrkeNxyF3p4l3ifeUxiE4LFAaN4IOAntRZ hdRRWWr4YkOpnRfmUeU+jtRU6TQWBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555085634; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hVnledz5uT+xLmBb4lxzteBXSEhZ/0ivhBAAtHo8eJU=; b=XKMkKi1dwNZtUXgT3j3+h5uJWr4IjNyHCCz4AUj2N3ERVmuJjDXGGVtW bDpE5I3NYJB391bH0avYnFf4q0YGDm5dbUxcqt/9BJksASnV6m0LjvnTDZ gEcIE0VcHdvvbTZG6sF7JSsr3t7pmlaQWDsL9yjNe+eP8jNh9N0IWE324n m2KuotTe3+6NZSdjI0EvK0dhhKRZJBZL6I/tD164zJHYCJYzQCfSpYv5fG YKF/0TzlVqdYDANQW8CE+DEM3U8RlXJQ+OtuglauwMoJ85dVN+oexH3gpy v7SezzhPsbNWfpBpTt4edCyoclOkmwfZtAXxlubk35BIeO0+KsCtbA==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id C03F5F80706 for <dmarc@ietf.org>; Fri, 12 Apr 2019 12:13:54 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Fri, 12 Apr 2019 12:13:54 -0400
Message-ID: <1944287.uG7mQ2khBI@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CABuGu1oD=vnCqjCaaSt_Zhvo0btTz7vCfk8vXwP8jx_NdhhyNg@mail.gmail.com>
References: <CABuGu1oE+W7_==GxG0Qmo9WxcPWm5in50EZwU+kSEJ4a0=QZzA@mail.gmail.com> <2560485.41NbCdns5Z@kitterma-e6430> <CABuGu1oD=vnCqjCaaSt_Zhvo0btTz7vCfk8vXwP8jx_NdhhyNg@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/jy0EH4i_siV4NsU4TCy5ActK4Jg>
Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02
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 Apr 2019 16:14:03 -0000

On Friday, April 12, 2019 08:23:01 AM Kurt Andersen wrote:
> On Thu, Apr 11, 2019 at 7:57 PM Scott Kitterman <sklist@kitterman.com>
> 
> wrote:
> > On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote:
> > > More substantively, in Appendix A, the case is being advanced for
> > > "concerns
> > > associated with Multi-organization PSDs that do not mandate DMARC
> > > usage".
> > > I'm not sure why "multi-organization" is an appropriate qualifier, nor
> > > as
> > > to what mandated DMARC usage has to do with any of the privacy concerns.
> > > Neglected DMARC usage is what leads to the spillage up to the PSD level.
> > 
> > When you say "Neglected DMARC usage", it gives the impression that you
> > think
> > not participating in DMARC is somehow negligent.  It's not.
> 
> I'm using that term in the context of what you are deeming "mandated
> usage". Hence, not doing it is neglecting that mandate.

OK.  I didn't get that.

Agreed that for an organizational domain in a PSD that mandates DMARC, not 
having an organizational DMARC record is neglectful.  In that context, I think 
it's perfectly reasonably to say that if you don't follow the rules, you get 
the consequences (in our case the PSO gets your reports).

Somewhat similarly, for a .bigcompany PSD, it's really an internal matter if 
they want reports to the PSO or various subdomains.

So there are two criteria for is there a privacy risk in my view:

1.  Is DMARC a requirement for organizations within the PSD?
2.  Are multiple organizations represented with the PSD?

Hopefully this ASCII art truth table will come out OK (leading '/' represent 
negation (i.e. not required and not OK):

      |One  | Multi |
      |org  |  org  |  
------+-----+-------+
DMARC |     |       |
Req   | OK  |  OK   |
      |     |       |
------+-----+-------+
DMARC |     |       |
/Req  | OK  | /OK   |
      |     |       |
------+-----+-------+

In the lower right corner of the table where I see the problem, there's no 
mandated DMARC usage, so the opt-in/opt-out problem exists.  I hope that makes 
it clearer why I used multi-organizational as a qualifier.

Scott K