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

Dotzero <dotzero@gmail.com> Tue, 04 February 2020 20:25 UTC

Return-Path: <dotzero@gmail.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 003FD1208CA for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 12:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 KgwPUAcl4gkA for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2020 12:25:32 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA33C1208C7 for <dmarc@ietf.org>; Tue, 4 Feb 2020 12:25:31 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id p17so48366wma.1 for <dmarc@ietf.org>; Tue, 04 Feb 2020 12:25:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M7tohPFTwyFd4SclqL27/tqoPrwUKyhxsdmcf6HlXxg=; b=AWPDOCOBRCAAA7MRDQS5gB50Go9qOsuhCmc1R1GPvoDVoOVoRpOm51kHtZTqwaebk/ 2rSisuCZMO4G+LyCLi42AvfRTbsiELWA5w879dT0ki3RvEoLBHQqqaS3F65Ep+lYk5TR DIK8oMFVe28WfFJVIzyaas8OPYTcQy8kxkKPwM7gCMiOUBE4gAfii7FiZ6Gz2C9FyGMR 0uecAjeK0CYcSGz+PlIU23ewZUtOcl+GkAUwFRq5YPXvXnZru8q6KGZsRrqR5UJpol8Y LXWNh8f/FqxlI8NuMtzRaj2iiSLfJxz1SRZaaJkXtNwcLSyIeajTFYNdV5AnCE8xeA7r 1Rxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M7tohPFTwyFd4SclqL27/tqoPrwUKyhxsdmcf6HlXxg=; b=c7DNDIQraYiner/jn4Kz5MEr0S5PAVOzgEpLnYGw35UC1FeR7+2zExoVGNgE7HyW0a QEkk20Xvmfy1kfFXLr7g+5KmoHbUEKmFeTET2etx8JXU7LbZsTPllJnXe3LUooNAj3vq /i96E+aUL8TFuMXua48+OcitRcD+VFpyw3iHpV74A5PYBi0nlFBthLKBrZWCRlU/dhep nSwWsiS60U9aUcFA95CalEoAFTqs/NdlsPNcKRJ/k9dY1e5DmdV7yCGIrcfEwHs7ySX6 5Z+ea7Y2tyuIy0EWssp1X62JM8so4CkmEFi9auQdDrjecVJqLYeppp7Hi0ow6IpYQOAb eEQw==
X-Gm-Message-State: APjAAAUfXsLBjBp/A6fMUHsJ8WyDnZ1PPfXrnAQSP2u8Ints75xdKF8y e0jBF5DjPLLrmrwyG+PoYVwW6IQ++uuyznKUEWBPVfFN6Og=
X-Google-Smtp-Source: APXvYqxxoM7/MZzI6QdzFEq3vKuFmOjGgD5axyPlePClaq+oiHkTZpwN5ftzfAFZcN/4+a2Qf6WH78jSd6ZnTSQ4PQs=
X-Received: by 2002:a05:600c:2c06:: with SMTP id q6mr834939wmg.154.1580847930185; Tue, 04 Feb 2020 12:25:30 -0800 (PST)
MIME-Version: 1.0
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <CAL0qLwbp2hNrgF_xxhKRRODQ6HP=U5_K-r3Wtm1wJZOZcKup3g@mail.gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com> <CABuGu1obn55Y2=CuEYRYCEO3TYYNhYTsdkesQ67O61jRyfO=wA@mail.gmail.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <CAL0qLwZnomZJTbFB=dfFdw2vWg7B0ObRuoage3pcWaYmP9Kp4A@mail.gmail.com> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <CAL0qLwZjd2qhejctNK0BM7j=SscaE45Mm7U9iWJNvO-GuhEKQA@mail.gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com>
In-Reply-To: <CAL0qLwY-v-VS-Wai-aqGRPOj1i8HxqMrYybzsNJGzN2dTHvG9w@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Tue, 4 Feb 2020 15:25:06 -0500
Message-ID: <CAJ4XoYe4MKmCuFXhshzek97ABeHk1YzZCJof8EPKZSGJzJUzOw@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Dave Crocker <dcrocker@gmail.com>, IETF DMARC WG <dmarc@ietf.org>, Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Type: multipart/alternative; boundary="000000000000529ec2059dc5d7ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MwxYRPdaT3V0pUlje7Cjbumfsno>
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 20:25:35 -0000

I do not support publishing draft-ietf-dmarc-psd as is. Running code and
rough consensus.

I, as were a few others on the list, was part of the private effort that
eventually became the "DMARC team". I point out that until DMARC was
published openly, the experiment had absolutely zero impact on others and
the Internet at large. It was a closed system. Subsequent to publication
(not originally as an I-D), some receivers did take steps that some
considered coercive towards senders, but that was beyond the specification
itself. At a subsequent point, some (large) sender domains published DMARC
policies that were painful for both intermediaries as well as users with
accounts at those domains but which sent mail from other origins.

Someone pointed to Sender-ID as an example experiment. A very poor example
to choose. It was broken from the start. As an aside, I kept sending email
to the folks at Microsoft using @Microsoft.com email addresses by using
"Sender" to game PRA to get a neutral". Furthermore, it dragooned senders
who had no intention of participating in the experiment by reusing their
published SPF records in a manner they did not intend them to be used. I
also point out how long it took to put a stake in the heart of Sender-ID.
And yet even today we can find Sender-ID records littering the Internet and
even a few places doing Sender-ID checks. For some definition of "We", we
are good at additions and modifications but poor at deletes.

I am not against experiments, but having reread the entire thread starting
from Dave's post in August, I believe his concerns are valid. My question
to the chairs and the group as a whole is whether an experiment can be
constructed that is valid and useful without "comingling" PSD issues and
concerns with the core of DMARC at scale? That is, the group that is
seriously interested does their experiment amongst themselves to produce
data that supports and justifies such changes in the wild.

"Be conservative in what you do, be liberal in what you accept from others.
..."

Michael Hammer

On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Dave,
>
> On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <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.  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.
>
>>
>> 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.
>
>> 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.  Since that will take months, I've proposed a compromise, because
> I don't think that's strictly necessary to allow the data collection work
> to proceed.  The proposed compromise, then, is to do the work in hand, then
> rip the experiment down and apply whatever we learn from it to standards
> track DMARC, which is the next milestone.  That will include the separation
> of function you proposed, because we agree it's an improvement.  I believe
> the set of likely participants in the experiment are present on the list,
> and it can be made clear to them that they should have no expectation of
> the mechanism it describes surviving past the termination of the
> experiment.  So the path forward here comes down to whether the working
> group achieves consensus on that compromise, or whether the asserted risk
> of the experiment's structure leaking into the permanent deployed base
> warrants shutting it down before it starts.
>
> 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.
>
> 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.
>
> 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).
>
>
>> The real challenge for most IETF specs is community engagement, not
>>> engineering adequacy.
>>>
>>
>> Interestingly I would claim we have clearly achieved the former here,
>> though obviously not the latter.
>>
>> My sense is -- as has become common in the IETF -- an extremely small
>> core of folk interesting in promoting this work, rather than extensive
>> community interest.
>>
> That's probably true, but by that argument we should just terminate most
> of the email-related working groups because the critical mass we can get
> today is a fraction of what it used to be.
>
> Those sorts of existential questions can't be answered at this level,
> however.  I would claim the working group was chartered with the
> understanding that the participation here won't be like it was for, say,
> DKIM, or DRUMS, etc.  We're not in a position to fix that here.  We have a
> job to do, and we need to get moving again.
>
> -MSK
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>