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

Scott Kitterman <sklist@kitterman.com> Tue, 04 February 2020 15:30 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 140511200B2 for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 07:30:46 -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=0ULIYj3M; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XeXvP53F
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 rHNMNS-jM_m6 for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 07:30:44 -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 4301812011F for <dmarc@ietf.org>; Tue, 4 Feb 2020 07:30:44 -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 17B12F80308 for <dmarc@ietf.org>; Tue, 4 Feb 2020 10:30:43 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580830242; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KnHmWH6dqKUApvXtwU1JWLged1p+q+igFIywiVGWQWc=; b=0ULIYj3MdTNU+gHH86WM0b2o2GZZHqesgCZW7HuKgk/TuaYF9sbpsl8/ uy5I5WaEKgFOrNvTPnLNIu38UqgSCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580830242; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KnHmWH6dqKUApvXtwU1JWLged1p+q+igFIywiVGWQWc=; b=XeXvP53Fdn1SRXTBh6SwihEdaWCWQp3fINhb7K3hDsEtTxnvDNIdALtT AuTSmIlwb9ezQnkieJsbyxVBlwngsR87ver749GdVKtvqnxNueAp5E5FNN mKOE+H5iUeTjabzJJsHPvrkIiqSPIAT8qS4qOrbIIYMfF0Uj0v1ZbkLox1 upG4/cP4/9nhUtNVE6q9tiSsBzuzYVJKx4z6zKFMWHeJhc/eNPi2oGEf9O oruw2zKLQTcl1ka09qTuuu8D4sB23GJFk6uusA+JJHg7+AL2/4Y/KXnFtB KFaO6hD9CID2D9JJ9qXQ6AndukVt3Bd1z1U+FlZ/pd+bK0zYpxi5LQ==
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 D1ABCF801EA for <dmarc@ietf.org>; Tue, 4 Feb 2020 10:30:42 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Tue, 04 Feb 2020 10:30:41 -0500
Message-ID: <2041721.1BiOycRJ3A@l5580>
In-Reply-To: <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@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/TPpvR4mElhO8ogypsawU_ocSu4M>
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, 04 Feb 2020 15:30:46 -0000

On Monday, February 3, 2020 1:47:45 PM EST Murray S. Kucherawy wrote:
> Now, to the working group as a whole:
> 
> The chairs note that we have a duly and properly completed WGLC in hand.
> Still, Dave's concerns have validity, so they need to be considered by the
> working group.  Since we need to do *something*, we are now putting the
> question back to the working group, and we need to see some answers.  The
> chairs will not accept hearsay replies or opinions, or expressions of
> needing this work but not knowing how to engage; you either give your
> feedback on the list or privately to the chairs or Area Directors, or you
> are along for whatever ride results.  Please indicate, as soon as possible,
> where your support lies given the above.  We're not going to let this go
> additional months (probably not even weeks) without progress in some
> direction.

Personally, I think Dave is wrong.  I think he's given an assertion, but 
nothing beyond that.  Given that DMARC has been successfully deployed at scale 
depending on a list (PSL), I believe that's an adequate existence proof that 
Dave's assertion that anything depending on a list can't scale is not correct.

Dave's claim that the IETF hasn't done anything depending on a list may or may 
not be correct, I don't know, but that's not a technical point.  If the IETF 
was stopped by "we haven't done this before", we wouldn't have much of an 
Internet today.

That isn't to argue using the PSL to find the org domain is a technically clean 
solution.  It's not.  It's only less horrible than the alternatives.

> I will also say for the record that we don't find compelling the assertion
> that resources will not be dedicated to the experiment absent a document in
> the RFC Editor queue.  That constraint is fully external to the IETF, and
> it will carry no weight in the decision made here.  It should indeed be
> possible to run an experiment based on a document in any state at all.
> We're entertaining publication not because it must happen, but because that
> action (currently) has consensus, and it's our job to act on consensus.

I think the IETF tells external organizations not to use I-Ds [1], so I don't 
really understand this point, but I don't think it affects consensus much.
> 
> Dave also made an additional observation, that experiments expected to fail
> are not generally what the IETF produces.  I would quibble some with that
> wording: The working group doesn't expect the experiment to "fail", but
> rather expects it to be ephemeral.  Were we to refer to chapter-and-verse,
> there's nothing in RFC2026 (which defines "Experimental" as a document
> status) that precludes what the working group appears to be trying to do
> here.  As for whether the IETF generally should produce an Experimental
> document describing something ephemeral, I would claim that a working group
> or its chairs are below the pay grade where authoritative claims like those
> are made; it's the kind of thing about which the IESG makes proclamations.
> Accordingly, I've Cc'd our current Area Director to see what he thinks
> might happen if we were to send this up, and give him a chance to provide
> guidance in case that's the decision (but we won't wait long for that
> either).

It won't surprise you to find that I support publishing the draft substantially 
as is.  I believe there are some open questions described in the experimental 
portions of the draft that will take some operational experience to evaluate 
and having a stable reference will be useful for that purpose.

As a side note, I don't think this is anywhere near the most extreme 
experimental document that IETF has considered for publication.  The Sender ID 
RFCs conflicted with current Internet Standards and were still published even 
after an appeal on that point.  Having just re-read the IAB response to that 
appeal [2], particularly Section 3, I'm even more convinced that the DMARC PSD 
draft is well within the realm of what's appropriate for an experimental RFC.

Scott K


[1] https://ietf.org/standards/ids/
[2] https://www.iab.org/appeals/2006-2/iab-response-to-appeal-from-julian-mehnle-2-march-2006/