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

Douglas Foster <> Tue, 19 January 2021 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1FA13A14AD for <>; Tue, 19 Jan 2021 04:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 hbKq__01CgTg for <>; Tue, 19 Jan 2021 04:34:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1927C3A14AB for <>; Tue, 19 Jan 2021 04:34:25 -0800 (PST)
Received: by with SMTP id e27so4743098vkn.2 for <>; Tue, 19 Jan 2021 04:34:25 -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=saSJYo3vbwUsoFH4vpC9OtgK4bLyO85PVNM7XgFpo/g=; b=Jm6BA5HSlncQ6yWBNtLWuNM8rrd3FI93Xt2ttZxdeCnk/dtjReDtDLrEfdIyK0sHRx ojkmx2OWSzWFNOCWnrVQD3Wre6keb/IJe9m3UqxpholcWJ6kiSvxvLrUXqIdQ39iU2YH nL1ZE3GtPGQEDqCozgWs98crgQFrVLGUUc6bHaWM3nfr8RsbSJin25a3e/dH3b/XSkXr kEETekH3dNS9z3KGdPiIJbKNyFvtMMpOu0l/+CpUhS+++UUbbV/rd7kVlzRPT6oWENoD Q9feZeqwU14xwfGa6wGrjkyF8RqUCbvms2KmPi2eDvNJ5c5fVgLWsi1kFsolOhaFXjnC eVGQ==
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=saSJYo3vbwUsoFH4vpC9OtgK4bLyO85PVNM7XgFpo/g=; b=cYcnvuSimXEq+961k2C7pwE+W+5UHlkx+8liYeUq0ebetnX7jviGE9BnR2PvVaJPyB Xu5aPBYS+mONSTtygc/VQQF2zjvi0NyiXiPEIcff4HDvZNXQpScWG+yv1TBOfDw40Mhz JHwPKYmlQS24++SDHfsagePaafxTBs9vAFe6ffh2TAJ1eOKRIcDRK1TyTVDdlAX958L+ gHeAAes4dSYfDwP/wpmvBktf6ONRnDCqx0VQqb7/klU59AVBUHuOIWIdkQ4WwAzYLyjk MCzvzHG580LGpvZzkKr4sjRupF0y7GRvCJcbGnX18mgMs2C/iMOHiHEvc+WhwmZ3Y0Bs Ib9w==
X-Gm-Message-State: AOAM530LezJgOWQ9RzQji0AgVySHYu46f/QosVSrxiX/SlFZTgRp1l+Q qTWaGtE+s9IT5vmIpCvqTJBT2IYOljzAPlSZ/MU=
X-Google-Smtp-Source: ABdhPJxdVcZ7Nj38vO4M757IEc7K0pkKtxvJnShiwj8tljQaiyBDsQG3RH/d7zf2FMnNC1Q+GyUpbEuK3tI8CPlESUo=
X-Received: by 2002:a1f:4582:: with SMTP id s124mr2488830vka.7.1611059664984; Tue, 19 Jan 2021 04:34:24 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Tue, 19 Jan 2021 07:34:14 -0500
Message-ID: <>
To: "Murray S. Kucherawy" <>
Cc: IETF DMARC WG <>, "Dale R. Worley" <>
Content-Type: multipart/alternative; boundary="0000000000000b1c8c05b9400f73"
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: Tue, 19 Jan 2021 12:34:29 -0000

I raised objections to the definition of "non-existent", which never
received an adequate response before the discussion went silent.

DMARC checks the From  header address, which may exist only as an
identifier used for mass mailings.   These mailings are often sent by an
ESP using an unrelated SMTP address.    As such, the From address need not
be associated with any A, AAAA, or MX record.    I assert that the only
viable definition of non-existent is "not registered", as evidenced by
absence of an NS record.

I don't believe the proposed definition of "non-existent" is reliably true
even in the special case of interest for this document, impersonation fraud
occurring at the top of an organizational structure.   Example.PSD may
legitimately use mail.Example.PSD for email and www.example.psd for web.
 If the proposed condition MUST always be true, I have not seen that fact
demonstrated.   Since the document raises a general concern about
fraudulent use of non-existent domains, the definition used should be one
that can be generalized.,

Doug Foster

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.
> -MSK
> _______________________________________________
> dmarc mailing list