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

Scott Kitterman <sklist@kitterman.com> Wed, 05 February 2020 06: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 27EB3120096 for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 22:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gKscV6bo; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Sjv4kL1U
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 YKccbMXJi_jq for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 22:13:08 -0800 (PST)
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 07E4B1207FC for <dmarc@ietf.org>; Tue, 4 Feb 2020 22:13:03 -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 CFA75F80248 for <dmarc@ietf.org>; Wed, 5 Feb 2020 01:13:02 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580883182; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=onEcKcPTefsG3W+7DSJg9rVDjZ4zvA0i4nk1imHUH1w=; b=gKscV6boVyXTqZo2RHffLgOIGP1Xy/0y3DYu7ahGaxbhSvXfkVmLkWSc eX4PUxoxmEsPZ3UYSjS1UAoBp5zJDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580883182; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=onEcKcPTefsG3W+7DSJg9rVDjZ4zvA0i4nk1imHUH1w=; b=Sjv4kL1UsK3tP2gLK1/lSwSC0ldZd/VOpscrL0B/XAn7JWB3HB0sJjVW J7zPuyjHHjmEENC60LsP7GsAYWT9m3T6lYQ0TjrBeD34rSq1DdSmtSiXtv NsIK7KefRi8RlIYFZY/pI50w52p9lWs1IOiJjYxJGd2t2hlsPSygjnyy74 bY8/EdOZ6FFiXnMKhkjBrk29/sVYrorG6NGYxdd/hW2Ouei/XApW5VMz/8 gHsCy4LJG4bhueXvgtfga3AKhIRLDKig6Bm7By18AXo75UOt/z9BQPxHyr FhHPYEaLMzNU927xPCQZq9yhD0kfd6jyXwsG4QumIwqwacoz7LJCKw==
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 9C353F80027 for <dmarc@ietf.org>; Wed, 5 Feb 2020 01:13:02 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 05 Feb 2020 01:13:02 -0500
Message-ID: <4570465.bmySQvRiU0@l5580>
In-Reply-To: <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com> <74241ca2-7c32-1bef-759d-47bf48eb2a3d@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/hkD5uW1YTE5yLNJMleUDBi6hMYY>
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: Wed, 05 Feb 2020 06:13:11 -0000

On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:
> (I am trying to formulate a response on the higher-level technical and
> process issues under consideration, but decided to respond now on these
> particulars, since they are more focused...)
> 
> On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
> > Dave,
> > 
> > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <dcrocker@gmail.com
> > 
> > <mailto:dcrocker@gmail.com>> wrote:
> >>     Nothing I've worked on at the IETF with such a label is something
> >>     I would necessarily stand behind as Internet-scalable.
> >     
> >     Such as?
> > 
> > RFC 6541 comes to mind.  To the best of my knowledge, it's an
> > experiment that never even ran.
> 
> I don't recall that scaling limitation was an embedded and acknowledged
> fact about that spec. And with a quick scan I don't see anything about
> that in the document.
> 
> There is a difference between having some folk be critical of an
> experiment, versus have its non-scalability be an admitted limit to its
> future.  That is, you or I or whoever might know a spec sucks and can't
> succeed, but that's different from having the formal process declare
> that an experiment is /intended/ not to scale, which seems to be the
> case here.

This claim seems to me to be unrelated to anything in the draft.  Would you 
please point to where you found this?

> > Implementations shipped, but its use on the open Internet was never
> > detected or reported.  And I had my doubts about the scalability of
> > the second DNS check that was added to it, but it didn't seem like it
> > could go forward without.
> > 
> > One that wasn't mine: RFC 6210, an experiment to prove how bad
> > something can be.
> 
> There is a reasonable argument to be made that little about /any/
> security spec actually scales well, but that's such a cheap shot, I
> wouldn't dream of taking it.
> 
> However, yeah, "to find out how bad including hash parameters will be"
> does seem to provide an existence proof for using IETF Experimental to
> bench-test something rather than as a gateway to standard for that
> something.  sigh.
> 
> >>     But I would probably expect something at Informational probably
> >>     to scale, and anything with "Standard" in it certainly to scale.
> >     
> >     Laying any general expectation on an IETF Informational RFC would
> >     be a mistake, because there is so much variety in their content
> >     and intent.
> > 
> > Why would the expectations for Experimental be higher than for
> > Informational?  LMTP is Informational, and it certainly needs to succeed.
> 
> As a rule -- or certainly a solid pattern -- Experimental means that the
> document wants to be standards track or BCP but needs some vetting
> before being permitted that honor.  Informational docs don't have an
> expectation of making it to standards track.

Would you withdraw your objections if we made this informational?

> >>     So: Can you propose any sort of specific restructuring of the
> >>     document or the experiment that achieves the same goal as the
> >>     current version while also resolving your concerns?
> >     
> >     I'm pretty sure I've raised fundamental concerns about this work
> >     and that those concerns have not been addressed.  The simple
> >     summary is that the way to restructure this work is to go back to
> >     first principles.  But there doesn't seem to be any interest in
> >     having that sort of discussion.
> > 
> > I thought we were having that sort of a discussion right here.
> > 
> > Your position as I recall is that we have no choice but to take all of
> > this back to first principles and separate DMARC from the
> > determination of Organizational Domain (i.e., make them separate
> > documents) before PSD can proceed.
> 
> Unfortunately, that's accurate. At the least, I'd expect to see
> thoughtful responses and some breadth of support for those responses,
> countering the fundamental concerns I expressed. I don't recall seeing
> responses with such substance.
> 
> (One of the challenges for me, in trying to formulate the 'thoughtful'
> response I'm considering is to provide/repeat a concise summary of those
> fundamental concerns.  As I recall they were both architectural and
> operational.)

Help me understand.

Currently the proposal is:

PSD DMARC defines PSD relative to org domain and points to DMARC for how one 
finds org domain (no PSL reference in the PSD DMARC draft - there have been at 
times, but there aren't now).

You find this unacceptable, as I understand it.  What you think we should do is 
first split the DMARC spec into two so that:

PSD DMARC defines PSD relative to org domain and points to DMARCbis for how one 
finds org domain and DMARCbis points to a new spec that explains how to use the 
PSL to find the org domain (or some other method if it's agreed).

You find this acceptable, as I understand it.

Assuming that's correct, please help me understand what PSD DMARC is affected 
at all.  All it does is consume the org domain however DMARC/DMARCbis choose 
to define it.  I don't see as it makes a difference from a PSD DMARC 
perspective.

I get that you want to fix the architectural warts in DMARC and I don't 
disagree with you about working on that.  Where I get lost is how PSD DMARC 
has anything to do with it.  PSD DMARC could be done first, in parallel, or 
after the DMARC architectural work.  It would have no impact on that work.

I would like to understand your position, but I don't, so please help me out 
here.

Scott K