Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

From: [email-masked]
Date: Fri, 19 Mar 2021 07:09:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Experimental DMARC Extension For Public Suffix Domains
        Authors         : Scott Kitterman
                          Tim Wicinski
	Filename        : draft-ietf-dmarc-psd-11.txt
	Pages           : 14
	Date            : 2021-03-19

Abstract:
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) permits a domain-controlling organization to express domain-
   level policies and preferences for message validation, disposition,
   and reporting, which a mail-receiving organization can use to improve
   mail handling.

   DMARC distinguishes the portion of a name that is a Public Suffix
   Domain (PSD), below which organizational domain names are created.
   The basic DMARC capability allows organizational domains to specify
   policies that apply to their subdomains, but it does not give that
   capability to PSDs.  This document describes an extension to DMARC to
   fully enable DMARC functionality for PSDs.

   Some implementations of DMARC consider a PSD to be ineligible for
   DMARC enforcement.  This specification addresses that case.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-11
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 19 Mar 2021 17:28:29 +0100

On Fri 19/Mar/2021 15:09:31 +0100 internet-drafts wrote:
> [...]

Much better!

There's still a few style points that I'd propose.  They can be dealt with in 
auth48.

*Introduction*

The PSL is not mentioned yet.  Therefore:

OLD:
    This document specifies experimental updates to the DMARC and PSL
    algorithm cited above, in an attempt to mitigate this abuse.

NEW
    This document specifies experimental updates to the DMARC specification
    in an attempt to mitigate this abuse.

*Example*

Since the algorithm (last word) hasn't been mentioned yet:

OLD
    Defensively registering all variants of "tax" is obviously not a
    scalable strategy.  The intent of this specification, therefore, is
    to enhance the DMARC algorithm by enabling an agent receiving such a
    message to be able to determine that a relevant policy is present at
    "gov.example", which is precluded by the current DMARC algorithm.

NEW
    Defensively registering all variants of "tax" is obviously not a
    scalable strategy.  The intent of this specification, therefore, is
    to enhance DMARC discovering method by enabling an agent receiving such a
    message to be able to determine that a relevant policy is present at
    "gov.example", which is precluded by the current DMARC specification.

*Discussion* (optional)

The phrase "of the tree" is useless and can be deleted.  That way, the first 
appearance of the term "tree" is deferred to Section 2.2, where it is put forth 
cleverly, by implicitly recalling that the term refers to graph theory, since 
the root is near to the top.

OLD
    o  Branded PSDs (e.g., ".google"): These domains are effectively
       Organizational Domains as discussed in [RFC7489].  They control
       all subdomains of the tree.  These are effectively private
       domains, but listed in the Public Suffix List.  They are treated
       as Public for DMARC purposes.  They require the same protections
       as DMARC Organizational Domains, but are currently unable to
       benefit from DMARC.

NEW
    o  Branded PSDs (e.g., ".google"): These domains are effectively
       Organizational Domains as discussed in [RFC7489].  They control
       all subdomains.  These are effectively private
       domains, but listed in the Public Suffix List.  They are treated
       as Public for DMARC purposes.  They require the same protections
       as DMARC Organizational Domains, but are currently unable to
       benefit from DMARC.

*DMARC PSD PSL Extension*

Here comes the first appearance of the string "PSL:

OLD
    [psddmarc.org] provides a PSL like file to enable to facilitate
    identification of PSD DMARC participants.  Contents are functionally
    identical to the IANA like registry, but presented in a different
    format.

NEW
    [psddmarc.org] provides a file formatted like the public suffix list
    (PSL) in order to facilitate the identification of PSD DMARC participants.
    Contents are functionally identical to the identical to the IANA like
    registry above, but presented in a different format.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Mar 2021 16:54:20 -0700

Just to nit-pick:

> There's still a few style points that I'd propose.  They can be dealt with

After Last Call, please.  Don't wait for AUTH48 to process this feedback.

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 19 Mar 2021 20:17:52 -0400

Agree with Murray.

Also, I see changing "Algorithm" to "Specification" makes sense.

looking at the other suggestions

tim

On Fri, Mar 19, 2021 at 7:54 PM Murray S. Kucherawy <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Mar 2021 17:19:54 -0700

Good work on the updated phrasing, I'd make just a couple of changes to the
"tax" suggestion:

>     "gov.example", which is precluded by the current DMARC specification.

1 - delete the word "obviously". I really don't think such a statement
belongs in a spec and can lead us down infinite rabbit trails.
2 - s/DMARC discovering/DMARC discovery/

--Kurt

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 19 Mar 2021 20:38:40 -0400

>     in an attempt to mitigate this abuse.
Updated

>     "gov.example", which is precluded by the current DMARC specification.

Added Kurt's suggestion and put in a "the". Now reads as

Defensively registering all variants of "tax" is obviously not a scalable
strategy.  The intent of this specification, therefore, is to enhance the
DMARC discovery method by enabling an agent receiving such a
message to be able to determine that a relevant policy is present at
"gov.example", which is precluded by the current DMARC specification.

>        as DMARC Organizational Domains, but are currently unable to
Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Mar 2021 12:41:22 +0100

> Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.

Oops, I missed a couple of those "Public Suffix List" entries.  That term was 
where the conundrum stemmed from, possibly because we're unsure how much we 
want to bind DMARC to the only PSL implementation we know.  That's why we want 
to avoid that term.

OTOH, the term "Public Suffix Domain" (PSD), seems to be sound.  It is often 
defined as "a domain under which multiple parties that are unaffiliated with 
the owner of the public suffix domain may register subdomains."  We can say 
that a domain "formally is a PSD" rather than it "is listed in the PSL".  The 
faint semantic difference between the two phrases is the source of the conundrum.

Being a PSD refers to a kind of contract.  ICANN mentions the above definition 
in a Policy Update issue[*], referring it to an expired IETF draft.  Should our 
I-D include such a definition?

Best
Ale
-- 

[*]
ICANN Policy Update | Volume 15, Issue 5 | Pre-ICANN53, June 2015
https://www.icann.org/resources/newsletter/policy-update-2015-06-16-en

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 21 Mar 2021 18:03:47 -0400

All

Alessandro had some very good suggestions, but I was looking at the
document,
there were a few other mentions of PSL and I wanted to think it through.

I have some suggested text I'd like to hear some feedback on.

First though, in going over the document again, I also
found where the word "from" was repeated twice in Appendix C.2,
and I updated the reference to RFC5226 with RFC8126

---

In the Introduction, the suggested change is

OLD

   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.

NEW
   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.  Currently the
   public suffix list being used is the most common one that is
   maintained by the Mozilla Foundation and made public at
   http://publicsuffix.org [1].

The document never points to the current PSL, only to 7489. What I'm adding
is more informative to assist folks reading this who are not immersed in
DMARC.

OLD

NEW

   This document specifies experimental updates to the DMARC
   specification cited above, in an attempt to mitigate this abuse.

In Section 1.1 "Example"

OLD

NEW

   Defensively registering all variants of "tax" is obviously not a
   scalable strategy.  The intent of this specification, therefore, is
   to enhance the DMARC discovery method by enabling an agent receiving
   such a message to be able to determine that a relevant policy is
   present at "gov.example", which is precluded by the current DMARC
   specification.

In section 1.2 "Discussion", this will change.

OLD
      as Public for DMARC purposes.

NEW

   o  Branded PSDs (e.g., ".google"): These domains are effectively
      Organizational Domains as discussed in [RFC7489].  They control
      all subdomains of the tree.  These are effectively private
      domains, but listed in the current public suffix list.  They are
      treated as Public for DMARC purposes.

In Appendix B.3, the "PSD Extension" is slightly changed.

OLD

   [psddmarc.org] provides a PSL like file to facilitate
   identification of PSD DMARC participants.  Contents are functionally
   identical to the IANA like registry, but presented in a different
   format.

NEW

   [psddmarc.org] provides a file formatted like the Public Suffix List
   (PSL) in order to facilitate identification of PSD DMARC
   participants.  Contents are functionally identical to the IANA like
   registry, but presented in a different format.

----

Welcome feedback

thanks

tim

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Mar 2021 12:12:51 +0100

>     http://publicsuffix.org [1].

I like this approach.  However, it may conflict with a minor issue reported by 
Dale last year, which I quote:

  - It would be very helpful if the Introduction could state, in a few
    sentences, the purpose and operation of DMARC, thus informing the
    reader of the framework whose deficiencies this document attempts to
    address.  In particular, one shouldn't have to read the DMARC RFCs
    to be able to read this document and understand its general import.
https://mailarchive.ietf.org/arch/msg/dmarc/0SG2-c3BnOakafKWnseuMKXBVIE

To help casual readers, PSL should be introduced after PSD is clarified.  This 
paragraph about the PSL could be moved downward (for example to Section 3), and 
replaced by a new one introducing PSD instead.  Such a paragraph could perhaps 
be worded around something like this:

     A public suffix domain (PSD) is a domain under which multiple parties
     that are unaffiliated with the owner of the PSD may register subdomains.  A
     domain registered that way is an organizational domain, and its subdomains
     can be assumed to be administratively affiliated with it (although in some
     cases they represent independent entities.)

>        treated as Public for DMARC purposes.

I'd weaken a bit the statement about the policies of Charleston Road Registry 
Inc.  Then, semantically, .google is not treated as a PSD because it's listed 
in the PSL, which could possibly happen because of a maintainer's passing 
fancy, but because it is actually operated by a public registry, as required by 
an ICANN contract[*].

     o  Branded PSDs (e.g., ".google"): These domains sound very much
        like Organizational Domains as discussed in [RFC7489], since they
        control all their subdomains.  However, formally they are public suffix
        domains, operated by a public registry.  Therefore, they are currently
        treated as PSDs for DMARC purposes.

Best
Ale
-- 

[*] https://archive.icann.org/en/tlds/application-process-03aug00.htm#1d

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 22 Mar 2021 08:37:10 -0700

>    present at "gov.example", which is precluded by the current DMARC

Tim,

I still think that including the term "obviously" in the first sentence of
this snippet is a pejorative judgemental statement which is out of place in
a specification. Especially given that there are alternatives to
"registering" any such domains at all via the use of "trick" DNS servers at
the PSD level.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Mar 2021 08:40:55 -0700

> I still think that including the term "obviously" in the first 
> sentence of this snippet is a pejorative judgemental statement which 
> is out of place in a specification. Especially given that there are 
> alternatives to "registering" any such domains at all via the use of 
> "trick" DNS servers at the PSD level.

Even worse is the demonstrable fact that it is far from obvious to many 
people and businesses.  Buying up cousin domains remains an active line 
of effort for (some) companies.

Consequently, the requirement here is to explain why it isn't scalable, 
rather than to simple assert the fact.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
[email-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 22 Mar 2021 11:44:57 -0400

Oh shoot y'all I removed "obviously" once, then accidentally added it back
in.

My mistake.

On Mon, Mar 22, 2021 at 11:41 AM Dave Crocker <[email-masked]> wrote:

> people and businesses.  Buying up cousin domains remains an active line of
> effort for (some) companies.
>
> Dave [email-masked]
> 408.329.0791
>
> American Red [email-masked]
>
>