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

From: [email-masked]
Date: Sat, 23 Jan 2021 15:26:03 -0800

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
        Author          : Scott Kitterman
	Filename        : draft-ietf-dmarc-psd-10.txt
	Pages           : 14
	Date            : 2021-01-23

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.

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-10
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-10

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

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: Tim Wicinski <[email-masked]>
Date: Fri, 29 Jan 2021 09:59:30 -0500

All

We've done a number of updates to the PSD document to reflect the GEN-ART
review,
mostly to expand on the experiments.  There has been enough changes that we
want to do a short
working group last call.

To look at the differences, I would suggest looking at this diff from the
-08 version and the current version:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-10

This starts a *one week* Working Group Last Call.  Please review the
changes and offer up comments.
Offering suggestive text would be really useful as well.

This WGLC will end 5 February 2021

tim

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, Jan 23, 2021 at 6:26 PM
Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-10.txt
To: <[email-masked]>
Cc: <[email-masked]>

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
        Author          : Scott Kitterman
        Filename        : draft-ietf-dmarc-psd-10.txt
        Pages           : 14
        Date            : 2021-01-23

Abstract:

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jan 2021 07:51:10 -0800

On 1/29/2021 6:59 AM, Tim Wicinski wrote:
> This starts a *one week* Working Group Last Call. 

Sorry, but even the Abstract appears to be littered with problematic 
language.

I always try to provide alternate language, when I can, but in spite of 
having offered suggestions for this document in the past, I can't for 
this set.

> Abstract
DMARC does not have 'registrations'.

Also the occur/occured contrast has no obvious meaning to me. Really, I 
have no idea what's intended by it.

>     occurred; it does not permit a domain name to have both of these
"both" of what?  registration?

>     DMARC has shown a clear need for the ability to express policy for
Which domains?

>     to enable DMARC functionality for PSDs.
This is the definition of public suffix provided by the PSL folk:

"A public suffix is a set of DNS names or wildcards concatenated with 
dots. It represents the part of a domain name which is *not* under the 
control of the individual registrant."

>     domain on a public Suffix list to be ineligible for DMARC
seeks?

implementations don't 'consider' anything.

is 'ineligibility' really the essential issue?

d/

-- 

Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Jan 2021 12:15:02 -0800

> DMARC does not have 'registrations'.

It's referring to domain name registrations, not DMARC registrations.

> have no idea what's intended by it.
"exist"?
"take place"?
"are made"?
"are done"?

> "both" of what?  registration?

It's describing properties of nodes in the domain name tree.  DMARC's
current design stipulates that every node is either (a) a node below which
registrations can occur, or (b) a node at which a registration has
occurred.  An example of the former is "org", and an example of the latter
is "ietf.org" and its entire subtree.

>    DMARC has shown a clear need for the ability to express policy for

The intent is to augment DMARC's ability to describe the domain name tree
such that a node can be both (a) and (b) at the same time, for the purposes
of policy expression.  So those are the nodes (domains) of interest.

> control of the individual registrant."

That seems to say the same thing to me, though perhaps more crisply.

> [...]

Hmm.  Maybe that sentence can be struck entirely.  Is this a problem with
certain implementations only, or with DMARC as specified in 7489?  If the
latter, I think we can drop this because the main paragraph already says
this.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jan 2021 12:56:09 -0800

On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     Abstract
>>
>     Also the occur/occured contrast has no obvious meaning to me. 
>     Really, I have no idea what's intended by it.
>
> "exist"?
> "take place"?
> "are made"?
> "are done"?

The issue wasn't synonyms but semantics.  'registrations occurred' has 
no obvious DMARC meaning.

unless, perhaps, the meaning is 'domain names exist', but that still 
doesn't explain the contrast being drawn.

> current design stipulates that every node is either (a) a node below 
> which registrations can occur, or (b) a node at which a registration 
> has occurred.  An example of the former is "org", and an example of 
> the latter is "ietf.org <http://ietf.org>" and its entire subtree.

The word in used in the spec as:

"

    3 <https://tools.ietf.org/html/rfc7489#section-3>. Terminology and
    Definitions

Domain Owner:  An entity or organization that owns a DNS domain.  The
       term "owns" here indicates that the entity or organization being
       referenced holds the registration of that DNS domain."

and:

"

      3.2 <https://tools.ietf.org/html/rfc7489#section-3.2>.
      Organizational Domain

    The Organizational Domain is determined using the following
    algorithm:

    1.  Acquire a "public suffix" list, i.e., a list of DNS domain names
        reserved for registrations. "

(The later reference to the Tag Registry is presumably irrelevant here.)

> The intent is to augment DMARC's ability to describe the domain name 
> tree such that a node can be both (a) and (b) at the same time, for 
> the purposes of policy expression.  So those are the nodes (domains) 
> of interest.

My frustration is that a document that reaches wg Last Call should not 
have language that is this confusing, especially about its fundamentals 
and especially given how much revision it has already gotten.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791