Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04

Scott Kitterman <> Sat, 13 July 2019 02:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A92A1120074 for <>; Fri, 12 Jul 2019 19:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=VF2DK/Gn; dkim=pass (2048-bit key) header.b=R01KtZ9X
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3NU5sN1oSmlm for <>; Fri, 12 Jul 2019 19:06:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 355AB12009C for <>; Fri, 12 Jul 2019 19:06:10 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id EBF89F8071F for <>; Fri, 12 Jul 2019 22:05:38 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1562983538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kr3Q4FTtRwSDxdtZqLLLxkj6z7B+IfrtLXJ9P1789fI=; b=VF2DK/Gnrf8772zkWrQPKlTh83ZodzMuN+D90YkIH+ngdmSaviTjYCIh eLsfdiWoS4ykmVNim6PrB0eXO3TeDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1562983538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kr3Q4FTtRwSDxdtZqLLLxkj6z7B+IfrtLXJ9P1789fI=; b=R01KtZ9XtAsWGM4YVoIR3c8C/O6i606lXB2gMM+CzZKc9Q6CmYab4/Lr NiXvWOVClDFc5T6OkFlUakwzLDJcK4CD52z6ebh5OZseQMzdZ0g6wRoVVJ SWmP7LkWw6rlsN8w+u4PFMviGvVTcJ0qr3D9v8AM/RMidtu+6P0pshQbRS kh/pcrfc0xwojsLLts9h9EqU7Gq3V5QQ6LWOZjzC+WAKm562gtD0o34mp+ +qN3SsiSGCeI3cH22A+mABp4a/7BObl8E9tYuZU6b/71gMzNnGJ4qEBsaG 96BJEg51nWbMFTRUdwurYc5+UZBPtw03op0I8DD4MwM+I+M3dFz3Vg==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id B9C03F80607 for <>; Fri, 12 Jul 2019 22:05:38 -0400 (EDT)
From: Scott Kitterman <>
Date: Fri, 12 Jul 2019 22:05:38 -0400
Message-ID: <3567849.MR6BRsP4iS@l5580>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04
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: Sat, 13 Jul 2019 02:06:14 -0000

On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote:
> Please note that I did not review Tim's comments in detail so some of the
> following points may have been covered by him previously.

Thanks.  I'd forgotten about that set of comments.  I think they mostly relate 
to the understandability of the front matter, so I'll discuss that further in 
that thread.

> *Page 2 contains the following paragraph:*
>    This memo provides a simple extension to DMARC [RFC7489
> <>] to allow
>    operators of Public Suffix Domains (PSDs) to express policy for
>    groups of subdomains, extends the DMARC [RFC7489
> <>] policy query
>    functionality to detect and process such a policy, describes receiver
>    feedback for such policies, and provides controls to mitigate
>    potential privacy considerations associated with this extension.
> This extension does not really allow PSDs to express policy for
> "groups of subdomains" unless you take the perspective that "all or
> none" are groups. Perhaps altering the language to say " express
> policy that would apply to subdomains..."?

I think Tim's suggestions address this concern.

> *The very end of section 1 says:*
>    DMARC [RFC7489 <>], by design,
> does not support usage by PSOs.  For PSDs
>    that require use of DMARC [RFC7489
> <>], an extension of DMARC
> reporting
>    and enforcement capability is needed for PSO to effectively manage
>    and monitor implementation of PSD requirements.
> I still fail to see how this proposal is necessary (or, potentially
> even useful) for the PSO to perform enforcement of their policies. I'd
> recommend either deleting the entire paragraph or refocusing the
> second sentence around the brand protective role that this proposal
> brings for abuse of non-existent subdomains below the PSD.

I think it can be deleted.

> *Section 2.2* "PSD DMARC includes all public domains..." --> suggest
> "PSD DMARC applies to all public domains..."

Seems fine.

> *Section 2.6* "...that a receiver is willing to accept" seems like it
> opens up a wide area if one applies considerations like
> DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this
> topic so I'll defer to that thread.
> *Section 3* should include the new "np" keyword as an update to the DMARC
> spec.
> *Section 3.5* This call-out makes it seem like information about
> non-existent domains is not desirable and useful for org-level DMARC.
> Can we modify the language to remove that implication? Perhaps "
> desirable and useful, just as it is for org-level DMARC operators."

There was a desire to say something specific about wanting data on non-existent 
domains.  I agree with your point.  What would you suggest saying to make the 
point that it's definitely desirable at the PSD level without implying it's not 

> *Section 4* Neglects the privacy implications of broken "receiver is
> willing to accept" conditions that may lead to additional leakage.
> Also in the third bullet point, "it's feedback" should not have an
> apostrophe.

Typo is fixed in git.

Isn't it always true that if local policy prohibits accepting certain DNS 
data, things will work out differently?  Does this need to be called out?

Scott K