Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

Tim Wicinski <> Fri, 22 January 2021 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 533B33A14EB for <>; Fri, 22 Jan 2021 12:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=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 kZJFizoof0KH for <>; Fri, 22 Jan 2021 12:35:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1867D3A14E9 for <>; Fri, 22 Jan 2021 12:35:07 -0800 (PST)
Received: by with SMTP id x137so6193705oix.11 for <>; Fri, 22 Jan 2021 12:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kTnJfWaApVmeF5sP6tdjCF9qD24FXMNWJrRSs77zFN8=; b=egQv0izODZ2jwXfPusmRDDNmQacb3VlE9NaaRpM3xa1D0AYCPCzeSIgzKu1jnKS3qn eLzL5jWHVYMj8A7dFzsDNX46fYAg7MRJjFvJ8ENOWsxQt19Jl5rAoZjqRROpsXIOyFpn eHsIWKgtgy6XfV0uGvCFKDCAtXCfiQ/VO8TwTZHTfanhb0EfTHmNxzM7euEhPmhDHbEZ yeVs5yiOb6WlQqfRGoR89VOcmYScxlErNFTvvI/RETQGWKHQiBOn7oE4/RJGyr2igY3N uvIetVGILEB1nCcM5uT+QSbMiuxsuaIbBaE4yYTLYaYNbYF1uNfImEnj/wOPXRz7CLLv VleA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kTnJfWaApVmeF5sP6tdjCF9qD24FXMNWJrRSs77zFN8=; b=FkqlRhS8NE89RPyffsRe0JkVSWkZOTtQ3Ob2AvISdN4C5qBEPHxKKzF9swprIWD/E6 AUjrQkFpwJQfDkFFJZG04V3QtQL7JeCQsk+0IKK8q14EzBIX6UjvXkVFR8faVMYIIzeQ 7t6gL2WAOd0BYgJGyKNHVZY4QV5EwVeppRXftzkm3SlXoW+HPAERFfnP5A2L8tarrrnQ yHtWKohny9VIsPXU9lqtvEKArqyfrbsfJxEL3SBSWM1JjjBrA0Cnst3MlJTVGiNV/g4P i98+vHEjvBrfzC+zyao8KlYnU5nQPNo9sulT8S3zitY2THNua2n5VaT4cglcGlBdVdBg q7RQ==
X-Gm-Message-State: AOAM531M8pV7DTaZwVxpyTtqBfAEf4gvg1w5SQ0it/r0mLd8zX42nzi/ 2jveEigw3Aj4RBbOSmlycb1dzhazaB1HItEVg3M=
X-Google-Smtp-Source: ABdhPJyRhyUncFet3C5ATV9Z2/Wns7gVPW/b7ExayBaTDqspIycVQ8RsfihPELLQU7YYS+TuA7WkIBTQj9WsLCqkhHk=
X-Received: by 2002:aca:54d1:: with SMTP id i200mr4420503oib.21.1611347706242; Fri, 22 Jan 2021 12:35:06 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Fri, 22 Jan 2021 15:34:55 -0500
Message-ID: <>
To: "Murray S. Kucherawy" <>
Cc: IETF DMARC WG <>, "Dale R. Worley" <>
Content-Type: multipart/mixed; boundary="000000000000a4a38d05b9831fd3"
Archived-At: <>
Subject: Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08
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: Fri, 22 Jan 2021 20:35:12 -0000

On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy <>

> In the interests of getting this document on its way, I'd like to suggest
> the following edits in response to Dale's most recent message.  If the
> working group concurs, we can finally get this out to Last Call.
> My goal as an AD here is just to get the GenART feedback addressed, but
> the text is being submitted as a WG contribution for discussion and
> consensus consideration, not as a demand.   Please process accordingly; I
> believe the agreement is to do another WGLC on the document before it goes
> on its way, so the sooner consensus is reached on all of this, the sooner
> it goes.
> First, a suggestion of my own that I think I saw elsewhere, but it's not
> in Dale's reply: In several places there's a reference to "DMARC
> [RFC7489]".  That's appropriate the first time the reference is made, but I
> think after that you can just say "DMARC" when referring to the protocol
> generally, or to "RFC 7489" when you need to make a specific section or
> text reference.  They don't need to appear together everywhere.
> I think Dave's original feedback has been addressed -- good stuff -- so
> here are my suggestions around what's left:
> On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley <> wrote:
>> My apologies for not tending to this promptly.
>> In regard to the description of the experiments, the result criteria are
>> rather subjective, but I don't see that as a problem.  It does seem to
>> me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
>> too narrow, as only the 3rd experiment seems to be about privacy
>> issues.  A title as generic as "PSD DMARC Experiments" would be fine.
> That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
> we want to treat it all as one common thing.
>> Although I note that even the -09 does not define "PSD", only "longest
>> PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
>> equal to "PSO Controlled Domain Name", though, or rather to some related
>> set of them.  That needs to be cleaned up in some way.
> PSD appears to be well defined in Section 2.2.
> In section 3.5 and later there is the phrase "[this document] longest
>> PSD".  I'm not sure, but I think this is supposed to be "longest PSD
>> ([this document] section NN.NN)".
> Agreed.
> I believe that my strongest critique was that section 1 is difficult to
>> understand if one does not already understand DMARC, and it does not
>> seem that the section has been revised.  Re-reading it, I notice that it
>> says "DMARC leverages public suffix lists to determine which domains are
>> organizational domains."  Ignoring that I dislike this use of
>> "leverage", a critical point is that it takes the existence of public
>> suffix lists a priori -- indeed, this use of "leverage" generally means
>> that the leveraged thing already exists and one is now extracting
>> additional benefit from that.  Whereas I've never heard of public suffix
>> lists and would naively expect that they are difficult to create and
>> maintain.  It might be better to say "DMARC uses public suffix lists to
>> determine which domains are organizational domains.  Public suffix lists
>> are obtained/maintained/distributed by ..."
> Replace all of Section 1 with this (ignore funny line wrapping):
>    DMARC [RFC7489 <>] provides a mechanism for publishing organizational
>    policy information to email receivers.  DMARC allows policy to be
>    specified for both individual domains and for organizational domains
>    and their sub-domains within a single organization.
>    To determine the organizational domain for a message under evaluation,
>    and thus where to look for a policy statement, DMARC makes use of a Public Suffix List.
>    The process for doing this can be found in Section 3.2 of the DMARC specification.
>    DMARC as specified presumes that domain names present in a PSL are not
>    organizational domains and thus not subject to DMARC processing; domains
>    are either organizational domains, sub-domains of organizational
>    domains, or listed on a PSL.  For domains listed in a
>    PSL, i.e., TLDs and domains that exist between TLDs and
>    organization level domains, policy can only be published for the
>    exact domain.  No method is available for these domains to express
>    policy or receive feedback reporting for sub-domains.  This missing
>    method allows for the abuse of non-existent organizational-level
>    domains and prevents identification of domain abuse in email.
>    This document specifies experimental updates to the DMARC and PSL algorithm cited
>    above, in an attempt to mitigate this abuse.

> Looking at the second paragraph of section 1, I notice that despite all
>> the special terms for classifying domain names in section 2, the example
>> in this section does not describe which of the domain names that it
>> mentions fall into which of these classes.  E.g. "" is
>> said to be registered, but it looks like it is also the organizational
>> domain, and "gov.example" is its longest PSD.  It would also help to
>> mention that "" is "registered at" "gov.example" to
>> introduce the details of the usage "registered at".
>>     Suppose there exists a domain "" (registered at
>>     "gov.example") ...
> Introduce a new Section 1.1: "Example" with this:
>    As an example, imagine a country code TLD (ccTLD) which has public
>    subdomains for government and commercial use (".gov.example" and
>    ".com.example").  A PSL whose maintainer is aware of this country's domain structure
>    would include entries for both of these in the PSL, indicating that they are
>    PSDs below which registrations can occur.  Suppose further that there exists a domain
>    "", registered within ".gov.example", that is
>    responsible for taxation in this imagined
>    country.
>    However, by exploiting the typically unauthenticated nature
>    of email, there are regular malicious campaigns to impersonate this
>    organization that use similar-looking ("cousin") domains such as
>    "".  Such domains are not registered.
>    Within the
>    ".gov.example" public suffix, use of DMARC has been mandated, so
>    "gov.example" publishes the following DMARC DNS record:
>    [remainder of -09's page 3, the example, unchanged]

> Introduce a new Section 1.2: "Discussion" comprising the remainder of -09's Section 1.  In the first paragraph, between "simple" and "extension", add "experimental".
> A suggestion for 2.4:
> NEW:
> The longest PSD is the Organizational Domain with one label removed.  It names the immediate parent node of the Organizational Domain in the DNS namespace tree.

I also changed the title to "Experimental DMARC Extension for Public Suffix

I need to go over the next batch.

I have the XML in my repo:
and will send a pull request when i've gone back over things.

I do attach the rfcdiff I created locally for folks.  that may help

big thanks Murray