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

Dave Crocker <> Wed, 05 February 2020 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F85B12001A for <>; Tue, 4 Feb 2020 19:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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] 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 3ubeZAc2xI3Z for <>; Tue, 4 Feb 2020 19:20:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7C061201A3 for <>; Tue, 4 Feb 2020 19:20:17 -0800 (PST)
Received: by with SMTP id 66so601854otd.9 for <>; Tue, 04 Feb 2020 19:20:17 -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; bh=IG/aWzW/+pQzEfup8GJCsIciU+LKwzg9cD67Oyhn2J0=; b=bX9f3PQ2hKDXZBxIIMFpb7vTnCBiIsHZuenjmdWgdztpTe+NC2QC/LfgjwpaASKYY0 fdn+WMoRvbXSidxRA+u4uEor8Ebu5SDN4EcwmOXF6CEy0ZTb3ttEtRw3v+kcirkpaEXQ 7hD907tuvreRJkmmZNvTg1O3OnOfm5t54vuNl6q7hWBQoNl+rpTs7r2vKPbmV3DqHVAv X+2bDvyf97omMs/myvHMMenxNpbzcT2ZzvevfjNHDtM/3QLl9GnKllDV0kbwp3tZ3P3J 4np5ZpuzRRfamQ7011+gBzh5frWQz5kF2YRIe0/orps/qZod/Z3/2pCj0JHBKWlCurSw 1aKg==
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; bh=IG/aWzW/+pQzEfup8GJCsIciU+LKwzg9cD67Oyhn2J0=; b=FPnnkWH3bCZ6JkITBhubAxNXJqDdvJZmALd0vb+LnU9eHbSMJusRBE9GJc33T6AolB JSfu507DjUD9388F1XnMnDPO5O4VdFH6C/qh8a++fQn4fPrAvx+0khjt/eI/I9efFv7A MuK/dgbJlnDbU1l5mQLS3x6i6Gl8ZeUbrgROUqLxR27GtR6jmY8g90Su2TE8obc4ukyQ Mqljij60Yh5hfATvJnnRwm/PDSRG+8JHV2ZkOlSQAs/dwYa0QeEAubN1sSmlaITPMmRl w5UCVUkBq7gRZkn1QnmZ4bkUPTcFuqRR4GdNr5Q0rhV4ZrZwq6CuGlfTkcV6AfV1luuZ FkSw==
X-Gm-Message-State: APjAAAVWg16FqYrPH4QIWAyNbKEtIc5MpYzSAv7iRN0EzXZmpSmZlJD+ jwqNom912drz6REOU+XFVQY=
X-Google-Smtp-Source: APXvYqxCGY3L27hjZqELbEdHoomIiepuGaKm6I6NZCqohVBI3VlaVCq4shxhVhcK0TDXas8HytWaKA==
X-Received: by 2002:a05:6830:15c2:: with SMTP id j2mr23095482otr.351.1580872816898; Tue, 04 Feb 2020 19:20:16 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:4c80:4186:9fa4:da5d:f255? ([2600:1700:a3a0:4c80:4186:9fa4:da5d:f255]) by with ESMTPSA id i12sm8590810otk.11.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Feb 2020 19:20:16 -0800 (PST)
To: "Murray S. Kucherawy" <>
Cc: IETF DMARC WG <>, Alexey Melnikov <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Dave Crocker <>
Message-ID: <>
Date: Tue, 4 Feb 2020 19:20:14 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E55BAD87CA4CBACCA9264DBC"
Content-Language: en-US
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: Wed, 05 Feb 2020 03:20:19 -0000

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

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

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


Dave Crocker
Brandenburg InternetWorking