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

Dave Crocker <> Mon, 09 December 2019 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D497C120096 for <>; Mon, 9 Dec 2019 08:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EraJ3auWpYNH for <>; Mon, 9 Dec 2019 08:44:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75DE512000F for <>; Mon, 9 Dec 2019 08:44:28 -0800 (PST)
Received: by with SMTP id d17so12799118otc.0 for <>; Mon, 09 Dec 2019 08:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=j6F6OMLxhA4P3gne6uoc2pgjPBSDVHoB7MO38WV7tR4=; b=UdtjNycNradaTO9acrQKdgs0lAoKHpIO29p0lgeNfc8D55lQm7U+FM41emiIpFHtgx xtwDKkCK6GTxA8S2Jx8y7/IbdY7E0liIIdbJYLMQGhoUhPmVhZQDA9/Lsv+7+VZ+DknV LqR2jocv0QYtcIqaoV30yJ2knIpRF/NO5tlH5CmYm7cf1P9Q/eW18+tKgdVYgCEhAfvm FwOuXlHWOr4DbbgssOKJWgyZQ9a732Wq57jjBckrpY6zbyFv4uVftcM4BBlcTmPlnCK9 S9XQ3jiTwVSGBewFhk77S7cXBXtYg4DyhDwShnLCNBml3veWzailCiFsPjML4jjKEchZ UOww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j6F6OMLxhA4P3gne6uoc2pgjPBSDVHoB7MO38WV7tR4=; b=eNGJk3w2ZMsR16mPigc35O2NPPvFeClGXFP5BIk/UrOz+LCljyLYImboZeGEI1Rkhf E9mjWtCp4vkgy01k2irc0OKKC0xZ+vMqdNNB1X5TDEGYQHAKJcGJump4zfValRoUkWTG Rszr1bpyulhuTT8x2LMbg4esQ3UAf6jDmJNq/4+44MHW3s+eCclQ4dQ7druVixMO9MxR kNXGr4kFxgJtrlUzY2QxyXoImQF5ezGZtY3BVFWjFYXhfy7Y8ez5UVysLQxvCceXjLZa Dfx6O40kKgLlNBJNFZeP/5LFuVHMo337qVovYadJ4gDTaVm3iAsXMQFE8W2j/0UPcdjN vvMg==
X-Gm-Message-State: APjAAAUFIs9o9M/v2KLZDCcI0oipv5k6s3DgJQEpcyUAbb+NbFyUproo Qp9IK3MHjpQtxxV7ZO9vuQ4=
X-Google-Smtp-Source: APXvYqxpLKNYy999PQi4A8ZYKDV6wQY/l/rT+Jl9meaSFMYBvV0GkdmWopiuXitxSYQnc/QapUcSDg==
X-Received: by 2002:a9d:6a8f:: with SMTP id l15mr21320302otq.59.1575909867526; Mon, 09 Dec 2019 08:44:27 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:4c80:794c:7c66:451f:c72b? ([2600:1700:a3a0:4c80:794c:7c66:451f:c72b]) by with ESMTPSA id y6sm91007oti.44.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 08:44:26 -0800 (PST)
To: "Murray S. Kucherawy" <>
Cc: Tim Wicinski <>, IETF DMARC WG <>, "Kurt Andersen (b)" <>, Scott Kitterman <>
References: <> <> <> <> <> <> <> <> <> <>
From: Dave Crocker <>
Message-ID: <>
Date: Mon, 9 Dec 2019 08:44:22 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2019 16:44:31 -0000

On 12/3/2019 11:42 PM, Murray S. Kucherawy wrote:
 >        I think there's a healthy
> dose of feeling that the experiment as it's currently designed
> couldn't possibly scale to "the entire domain namespace" and/or "all
> servers on the Internet", so in that sense from where I sit there's a
> built in safeguard against this becoming a permanent wart.  Rather,
> it's primed as a possibly useful data collection exercise.
The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale.  (While I think of this concern as
foundational to the IETF, it's a bit odd that nothing like it is
included in the IETF's "Mission and principles" statement.[1])

Perhaps even more importantly, I don't recall the IETF ever promoting a
specification that was /expected/ to be thrown away, in favor of then
doing the 'real' specification.  I do believe such work is sometimes
done in the I/R/TF.  Note that, for example, this view of throwing a 
spec away and starting over is quite different from wanting to let the 
market choose between competing specs.

Also, viewing this scaling limitation as a safeguard has recently and
notably proved wrong.  cf, DMARC.  It was designed for a very limited
scenario. Then it got re-purposed in the field, by some operators having
significant leverage.

Worse, publishing a spec always carries the likelihood of operational
momentum. If the spec has real utility, it tends to get implemented and
used.  That creates pressure against replacing it, because that's
expensive and possibly disruptive.

> Comparing it to the "obs" grammars of days of yore, the PSD proposal
> is much too expensive to become engrained as-is, whereas the old
> grammars were relatively easy to carry forward.

I don't quite grok the reference to "obs", and mostly think of the
introduction of that construct in RFC 2822 as an interesting idea that,
itself, failed.  (I see it as being instructive on the challenges of
designing for transition from an installed base.)

> Perhaps there are exampls of IETF experiments that have permitted 
> entirely starting over, but mostly those only happen when there is a 
> complete failure, and those typically are called experiments.
> ATPS (RFC 6541) was Experimental, and it flatly failed.  For a more 
> visible example, Sender ID was Experimental, and I would argue it did
>  too.  Should they not have been?

All sorts of experimental specs fail.  But they aren't /expected/ to
fail.  And they aren't expected to be unable to scale.

Mostly, IETF/Experimental is used to check whether a spec is
operationally viable -- it's expected to be but the community isn't
quite sure -- or to check for community interest.  The latter
constitutes market research, not technical research.

A pointedly friendly reading of the relevant Guidelines might seem to
support the publication under IETF/Experimental being proposed here, but
a more critical one probably doesn't and I think that this use of the
label doesn't really match common practice.[2]

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.)

The real challenge for most IETF specs is community engagement, not 
engineering adequacy.

Some additional thoughts:

The example that Tim added, of RFC 7706, is of an efficiency mechanism, 
not a basic and required addition to the architecture. The difference is 
important here.

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.


[1] Mission and principles


Dave Crocker
Brandenburg InternetWorking

Dave Crocker
Brandenburg InternetWorking