Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Scott Kitterman <sklist@kitterman.com> Tue, 10 December 2019 00:54 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 33DE912021C for <dmarc@ietfa.amsl.com>; Mon, 9 Dec 2019 16:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, 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=JI32lmzp; dkim=pass (2048-bit key) header.d=kitterman.com header.b=RaC9huS3
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 8baasLGRt-pz for <dmarc@ietfa.amsl.com>; Mon, 9 Dec 2019 16:54:14 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1835612002F for <dmarc@ietf.org>; Mon, 9 Dec 2019 16:54:14 -0800 (PST)
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 875A1F80267 for <dmarc@ietf.org>; Mon, 9 Dec 2019 19:54:11 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1575939251; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=lVIJ9YxYjPhVXlDHnUDRReEc748C/zpEHT76HENK4jE=; b=JI32lmzpgeOkE1ca68MO8Zm67wZSDdtddJiwxecgUMzk++o4eiK9QM3o RT9AWc8Lpvflvrv7vLy/aIcsL1WNDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1575939251; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=lVIJ9YxYjPhVXlDHnUDRReEc748C/zpEHT76HENK4jE=; b=RaC9huS3+KS8Z9+qlVnU0ZETD3ndydquM96+BWufTminvXvouZXpxxoo 3XPzAndqIE0ldIs/NelNZa01tjgFINENNR7ZR+VOJXrAqGK5bM/IAJwDME 4cbPUAvBGnU6zafAa+tVzmGjrBzKmnDwDCKy722CGpRHUsE15xrI4lj7u3 YD4exgBsKMICaLC3B1bXmP9V2c8hcFxpGjj6+PAArpVJHygQdlTWMWQUk+ RIDkWERR6aLz1ZeUZp4jLMTs9n/y8c28dFE85YJwfdUbdd2QFsHnJAO5PK yZO5jNzEPbmsiAkxGyw+5CU3xdIebwfkoMLbUUlSleRJ9PQW5nH4hw==
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 5B078F80096 for <dmarc@ietf.org>; Mon, 9 Dec 2019 19:54:11 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: IETF DMARC WG <dmarc@ietf.org>
Date: Mon, 09 Dec 2019 19:54:10 -0500
Message-ID: <92703458.QmNNAb80T6@l5580>
In-Reply-To: <CABa8R6vV3=mONXUehda_6C616CyEXPRjceSN8T+DcPmLQwcXOA@mail.gmail.com>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <CABa8R6vV3=mONXUehda_6C616CyEXPRjceSN8T+DcPmLQwcXOA@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/OIXOw745UuG-4YobAa0WkbPW15E>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Tue, 10 Dec 2019 00:54:16 -0000

On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
> On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker <dcrocker@gmail.com> wrote:
> > On 12/7/2019 12:11 PM, Scott Kitterman wrote:
> > >> Remind me again the the additional work is that might be too much?
> > >> Isn't it just another DNS lookup for the org domain -1... of which
> > >> there are maybe a couple thousand and easily cacheable?
> > >> 
> > >> This seems way less than say the additional work for ARC.
> > > 
> > > It's slightly more.  There's also a check to see if a LPSD (org -1)
> > > is a PSD > DMARC participant.  Exactly how to document that is the major
> > > unresolved question that we should evaluate experimentally.  It might
> > > be one of three
> > 
> > > things:
> > First, this sort of exchange highlights the need for considering basic
> > operational issues carefully and before publication.
> > 
> > Second, it highlights the challenges of doing that in a way that isn't
> > myopic.  What is easy/cheap for highly motivated, expert, well-resourced
> > participants might not be all that easy or cheap for the larger Internet
> > community.  (This is the operational side of scalability.)
> 
> Ah, re-reading the spec, I'd guess we're talking about the scalability of
> psddmarc.org.

It's only relevant for the purposes of the experiment.  Part of coming to 
consensus on the longer term plan would be making sure we have a scalable 
approach for determining PSD DMARC participants.

> [snip]
> 
> > Also, any suggestion to rely on a published list ignores the history of
> > problems with such lists, as well as at least requiring a careful
> > specification for the list and a basis for believing it will be
> > maintained well.
> 
> I mean, the PSL is already a maintained object.  Is this new detail
> something
> that has different ownership/privacy/etc concerns than the existing details?
> 
> I'm sure I probably missed this, but couldn't we avoid this question by
> just mandating
> no reporting for non-existing organizational domains?  Is that a
> non-starter?

It's one of the use cases we are trying to cover.  I don't know if that makes 
it a non-starter.

Scott K