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

From: Dale Worley via Datatracker <[email-masked]>
Date: Sun, 05 Apr 2020 18:10:31 -0700

Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  review-draft-ietf-dmarc-psd-08
Reviewer:  Dale R. Worley
Review Date:  2020-04-05
IETF LC End Date:  2020-04-08
IESG Telechat date:  not known

* Summary:

       This draft is on the right track but has open issues, described
       in the review.

* Major issues:

The privacy concerns described in section 4 are written as if there is
no certainty that the mechanisms described in the document properly
mitigate them.  So the document appears to be incomplete.  OTOH, since
this is an Experimental RFC, such mitigation isn't necessary if there
is commitment to do so later.  In that case, the section should
explicitly state that these are open issues and that there is an
intention of revising the document to mitigate them.

The text suggests that a mail receiver(?) that does DMARC processing
has knowledge of all PSDs.  This seems a priori unlikely and even
impossible to implement.  So this ought to be either explained at the
appropriate place or resolved technically.

* Minor issues:

The document has the (common) editorial problem that it is written by
people who are deeply familiar with the subject, and it's difficult to
read if one doesn't share that familiarity.  This is particularly
significant because DMARC is an e-mail facility that (ideally) will
affect all e-mail that is sent, so the target audience really should
be anyone who has a basic understanding of e-mail.  Three particular
elements of this are:

- 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.

- The "experiment" appendixes are unclear about what the experiments
  actually are:  what questions they are to answer, what actions will
  be taken, how the results will be evaluated.  Starting each appendix
  with an overview paragraph would be helpful.

- Forward references should be minimized so that a reader can
  understand the document in one pass.

As a derivative of the first of these elements, the terminology used
for the properties of domain names is not clearly defined.  In
particular, where does a registration "occur"?  The only term for
which I think the general audience possesses an unambiguous definition
is "the registered domain name", e.g. ietf.org.  Now I *think* its PSD
is ".org", but it might be "ietf.org", and I don't know whether the
registration of ietf.org "occurs" at ietf.org or .org.  Further points
I didn't understand are pointed out in the review of the
Abstract and Introduction.

* Nits/editorial comments: 

Abstract

I'm having quite a bit of difficulty figuring out exactly what the
Abstract means.  I'm sure that the working group clearly understands
what is meant, but the writing is just loose enough that I can't fix
the meaning.  To raise the immediate questions:

   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.

This sentence is quite good, as it introduces what DMARC is all about.

   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.

You want to make clear here that "registration" means "domain name
ownership registration" (which is what section 2.2 says).  Otherwise
it leaves open that there is some sort of DMARC registration that you
might intend, until the reader gets to section 2.2.

There's an ambiguity regarding "where" a registration happens.  E.g.,
does the registration of "ietf.org" "occur at" "ietf.org" or "occur
at" "org"?  It's possible that this could be simplified/disambiguated
by not using this term, but instead phrasing this in terms of domain
names that "are registered", and the allowed relationships between
them.

And it appears certain that there are DNS nodes where registrations
are only done *above* that node, e.g. "datatracker.ietf.org", which
this sentence (if taken literally) says is not permitted by DMARC.  Is
the property you want to declare "one node where registrations are
done cannot exist below another node where registrations are done"?

Or perhaps domain names like "datatracker.ietf.org" are of no interest
to DMARC because DMARC is never applied to messages for which that is
the relevant address?

   Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

This sentence doesn't make it clear what "these domains" refers to.

   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.

It would probably be clearer to use "domain name ownership
registrations" again here.

This sentence suggests that the registration of "ietf.org" "occurs at"
"org" and so "org" is a PSD.

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

This suggests that implementations believe that they know of all PSDs,
so they can "consider them ineligible for DMARC enforcement".  But
it's hard to imagine that that they can know that they know of all
PSDs.

An additional point, and I'm not sure how valuable this is, would be
to clarify "I'm holding an e-mail message in my hands.  What do I do
next?", that is, What address in the message is the domain whose DMARC
information is applied to the message?  And what indeed does DMARC
processing do to a message?  For most of the sentences of the
Abstract, this is not important, but it leaves the effect of the last
sentence unclear, as "DMARC is not enforced on messages whose *sender*
is in a PSD" is quite a bit different from "DMARC is not enforced on
messages whose *recipient* is in a PSD".  (Section 3.3 suggests that
the address in the From header of the message is the one that is used
for DMARC processing.)

It's unclear what exactly is the contents of a "public suffix list".
Naively, it appears that it is the list of domain names under which
names can be registered, but the text uses the term in the plural, so
there must be some additional structure.

Also, it seems there are some significant privacy matters addressed by
this document, and it's probably worth adding a sentence to notify the
reader of that.

1.  Introduction

A number of the questions about the Abstract apply to the Introduction
as well.  But generally, since e-mail is a subject that every reader
has a basic knowledge of, it would be useful to write the introduction
so that one did not have to have a knowledge of the DMARC architecture
to understand the introduction.

   "gov.example" publishes the following DMARC record:

   "v=DMARC1; p=reject; rua=mailto:[email-masked]"

   at

   _dmarc.gov.example.

Even better would be this aid to people who don't already know DMARC
implementation:

   "gov.example" publishes the following DMARC DNS record:

   _dmarc.gov.example.  TXT \
	"v=DMARC1; p=reject; rua=mailto:[email-masked]"

--

   the non-existent organizational domain of @tax.gov.example

I suspect you mean "t4x.gov.example" here.

   This document provides a simple extension to DMARC [RFC7489] to
   allow [...]

This sentence lists 4 important items, each of which is fairly long,
which together are the summary of the whole document, so it might be
useful to break this into a bullet-list.

2.  Terminology and Definitions

   In many cases the public portion of the DNS tree is [...]

What does "the public portion" mean?  I'm guessing it means "the names
not available for private registration", but you should be unambiguous
here.

   They are not available for private
   registration.  In many cases the public portion of the DNS tree is
   more than one level deep.

It seems like these two sentences are redundant and the flow of the
paragraph would be better if they were removed. ... Actually once they
are removed, it reveals that the next two sentences largely duplicate
the first two sentences of the paragraph.

   2.3.  Longest PSD

   The longest PSD is the Organizational Domain with one label removed.

   2.4.  Organizational Domain

   The term Organizational Domains is defined in DMARC [RFC7489]
   Section 3.2.

2.4 should be moved ahead of 2.3 to avoid a forward-reference.  But it
would be really helpful if the definition of Organizational Domain was
either summarized here or completely copied from RFC7489.  In
particular, if Organizational Domain is not the same as registered
domain name, that should be flagged.

   2.5.  Public Suffix Operator (PSO)

   A Public Suffix Operator manages operations within its PSD.

Better to explicitly define the possession relationship explicitly:

   A Public Suffix Operator is an organization which manages
   operations within a PSD, particularly the DNS records published for
   names at and under that domain name.

--

   2.6.  PSO Controlled Domain Names

   PSO Controlled Domain Names are names in the DNS that are managed by
   a PSO and are not available for use as Organizational Domains.
   Depending on PSD policy, these will have one (e.g., ".com") or more
   (e.g., ".co.uk") name components.

The second sentence is odd; is it useful?  Is it just to say "PSO
Controlled Domain Names may have one or more components."?

   3.1.  General Updates

   References to "Domain Owners" also apply to PSOs.

This change really ought to be localized to a specific textual change
somewhere in RFC 7489, in the say way that the other changes are
specific amendments to the DMARC algorithm.

   3.2.  Section 6.3 General Record Format

These section titles are difficult to read.  At first I thought there
was some typographical problem.  But you could clarify this as "3.2.
Updates to Section 6.3.  General Record Format".  Similarly for the
other subsections of section 3.

3.3.  Section 6.5.  Domain Owner Actions

   The mechanism for doing so is one of the
   experimental elements of this document.

I think that what this means is that the whole document is an
experimental "mechanism for doing so".  If so, I think it could be
better phrased

   This document is an experimental mechanism for doing so.

--

   3.4.  Section 6.6.1.  Extract Author Domain

   [...] when the domain name extracted by the receiver (from the
   RFC5322.From) is on the public suffix list used by the receiver.

This touches the question above about what a public suffix list is,
and how there can be more than one of them.  But without that
knowledge, it's hard to see which PSL is "used" by the receiver of the
message.

Also, it's not clear to me how *this* document creates a capability
which applies to domains that are on the PSL.  E.g., if an "np" is
defined for ".org", it applies to (that is, affects processing of
e-mail from) any "X.org" that doesn't have its own DMARC records.  But
I don't see how an "np" tag for ".org" affects processing of messages
from "example@org".

   3.5.  Section 6.6.3.  Policy Discovery

      (discussed in the experiment description
      (Appendix A))

Given that this text is nominally an update to the text of RFC 7489,
you want to disambiguate the binding of "Appendix A":

      (discussed in the experiment description
      ([this document] Appendix A))

   3.6.  Section 7.  DMARC Feedback

   See Section 4 of this document for discussion of Privacy
   Considerations.

Similarly to section 3.5, but also clarifying the scope of "privacy
considerations":

   See Section 4 of [this document] for discussion of Privacy
   Considerations for PSD DMARC.

   4.  Privacy Considerations

   The Privacy Considerations of [RFC7489] apply to this document.

This could be clarified as

   Additionally, the Privacy Considerations of [RFC7489] apply to the
   mechanisms described by this document.

--

   Providing feedback reporting to PSOs can, in some cases, create
   leakage of information outside of an organization to the PSO.

"outside" probably isn't the word you want to use here, as it is
easier to read "outside" as giving the original location of
"information" than to read "outside" as giving the direction of
"leakage".  Perhaps

   Providing feedback reporting to PSOs can, in some cases, create
   leakage of information out of an organization to the PSO of its
   domain name.

--

   To minimize this potential concern,
   PSD DMARC feedback is best limited to Aggregate Reports.  [...]

   [...] any Feedback Reporting related to multi-
   organizational PSDs ought to be limited to non-existent domains
   except in cases where the reporter knows that PSO requires use of
   DMARC.

I can't see where in the document that these principles are turned
into MUST statements that ensure the privacy issues are solved.

   The experiment is to evaluate different possible approaches.

Calling this an "experiment" suggests that these is an intended series
of actions whose result will answer the listed questions.  But there
doesn't seem to be any such actions listed.  The description makes it
sound like what is intended is continuing discussions in the working
group, but that wouldn't be an "experiment".

A.2.  Non-Existent Subdomain Policy

Similar questions arise for this section.  The second paragraph
suggests that the experiment is to see whether the "np" tag is
successful.

   There are also
   suggestions that it would be more generally useful for DMARC.

What does "it" refer to?  (Does it mean "this ability"?)

Appendix B.  DMARC PSD Registry Examples

In this appendix, it appears that the contents of the experiment are
clear in the authors' minds, but there is no summary at the top that
states what the experimental facilities are and the "big picture" into
which they fit.

Appendix C.  Implementations

   C.1.  Authheaders Module

What e-mail MTA is Authheaders an extension for?

[END]

---

From: Todd Herr <[email-masked]>
Date: Thu, 9 Apr 2020 15:54:02 -0400

Having reviewed the comments, I'm wondering if perhaps the following draft
rewrite of the Abstract section might be a first step to address many of
the points raised?

*AbstractDMARC (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 original design of DMARC applies only to domains that are registered
with a domain name registrar (called “Organizational Domains” in RFC 7489)
and nodes in the tree below Organizational Domains. Organizational Domains
are themselves nodes in the tree below domain names reserved for
registration, with the latter commonly referred to as “Top Level Domains”
(TLDs) (e.g., ‘.com’, ‘.co.uk <http://co.uk>’, etc.), although in this
document they will be referred to as Public Suffix Domains (PSDs).*

*Since its deployment in 2015, use of DMARC has shown a clear need for the
ability to express policy for PSDs. This document describes an extension to
DMARC to enable DMARC functionality for PSDs.*

*RFC 7489 describes an algorithm for a mail-receiving organization to use
in determining the Organizational Domain of an inbound mail message, and
this algorithm recommends the use of a “public suffix list” (PSL), with the
most common one maintained by the Mozilla Foundation and made public at
<http://publicsuffix.org/ <http://publicsuffix.org/>>. Use of such a PSL by
a mail-receiving organization will be required in order to discover and
apply any DMARC policy declared by a PSD.*

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

On Sun, Apr 5, 2020 at 9:11 PM Dale Worley via Datatracker <[email-masked]>
wrote:

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

-- 
Todd Herr

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 15 Apr 2020 22:32:32 -0400

> rewrite of the Abstract section might be a first step to address many of

I heartily endorse the sentiment behind this.  I think there are some
minor improvements that could be made, as I've noted below.

One point is that much of this information might be better put into the
Introduction, and only a skeleton of it put into the Abstract.  But as
they say, you write the Introduction after you've written the body of
the work, and you write the Abstract after you write the Introduction.

> with a domain name registrar (called "Organizational Domains" in RFC 7489)
> registration, with the latter commonly referred to as "Top Level Domains"
> (TLDs) (e.g., '.com', '.co.uk <http://co.uk>', etc.), although in this

In some way it would be useful to flag that RFC 7489 is the base DMARC
RFC.  Otherwise, the reader must just infer that, or look up the RFC.

There's also a point which seems to be very general, as it shows up in
RFC 7489 section 3.2:  all the text refers to a "domain" without
explaining *what* domain is extracted from the message under
consideration to determine the policy that applies to the message.  My
belief is that this is the From header in the message, but I've never
seen this stated.  So e.g.

"The original design of DMARC applies only to messages with From
addresses containing domain names that are registered ..."

This paragraph uses the phrase "domain names reserved for registration",
but I've not heard that term used in descriptions of the DNS.  And I
would expect say that "ietf.org" is "reserved for registration", not
"org" -- though I've never heard the phrase "reserved for registration".
The phrase that seems obvious to me is "domain names under which domain
names are registered, commonly referred to as 'Top Level Domains'...",
but that's somewhat awkward.

And Kurt Andersen notes that while .co.uk is clearly intended as one of
these domain names, it isn't, strictly speaking, a TLD.

> DMARC to enable DMARC functionality for PSDs.*

I'm not sure, but I suspect this could be clarified as "policy for PSDs,
and by inheritance, for domains under PSDs for which no explicit policy
is published." -- My belief is that nobody cares about mail claiming to
come from "person@org", but it's important to have a policy that
applies to "[email-masked]", inherited
from "org".

> this algorithm recommends the use of a "public suffix list" (PSL), with the

I don't know if this is useful, but I would suggest changing
"determining the Organizational Domain of an inbound mail message" to
"deriving from the domain name of the From address of an inbound mail
message the Organizational Domain to be used for DMARC processing".

> on a public Suffix list to be ineligible for DMARC*

I think you are very close to an Abstract/Introduction that is clearly
comprehensible to people who are not familiar with DMARC.

Dale

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 15 Apr 2020 22:44:57 -0400

> comprehensible to people who are not familiar with DMARC.

Considering this is an extension to DMARC, I don't think that's the target 
audience.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Wed, 15 Apr 2020 20:30:59 -0700

> Considering this is an extension to DMARC, I don't think that's the target

As an individual: everyone who reads the document stand-alone gets confused
by this lack of clarity (it's the common thread through all the last call
reviews so far), and a concise summary up top feels valuable both for this
evaluation process, and for any future consumers of the document. Whether
someone's familiar with DMARC or not, if they're reading this document,
what's the harm in spelling it out very clearly, especially if we have text
that we believe accomplishes this?

Seth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Apr 2020 20:39:11 -0700

On Wed, Apr 15, 2020 at 8:31 PM Seth Blank <[email-masked]> wrote:

> As an individual: everyone who reads the document stand-alone gets
> confused by this lack of clarity (it's the common thread through all the
> last call reviews so far), and a concise summary up top feels valuable both
> for this evaluation process, and for any future consumers of the document.
> Whether someone's familiar with DMARC or not, if they're reading this
> document, what's the harm in spelling it out very clearly, especially if we
> have text that we believe accomplishes this?
>

+1.  If even a small number of people (and the GenART review itself might
be enough) thinks it's in need of this kind of improvement, I would be
surprised if the IESG sends it back to the working group for revision.  If
the goal is to get this thing published so people can start conducting the
experiment, putting the work in now can only help you.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Apr 2020 20:42:26 -0700

Apologies:

> experiment, putting the work in now can only help you.

*wouldn't

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2020 03:43:41 +0000

On April 16, 2020 3:30:59 AM UTC, Seth Blank <[email-masked]> wrote:
>confused

Perhaps I'm too pessimistic, but I don't think it's possible to actually make this clear to anyone that isn't familiar with RFC 7489 without essentially turning this into a proto 7489bis.

If you want to add it and are confident we aren't diving into a deep, deep hole, I don't strongly object.  Just let me know what to add.

Scott K

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 21 Apr 2020 21:21:50 -0400

Scott Kitterman <[email-masked]> writes:
> [important discussion clipped for brevity]
> If you want to add it and are confident we aren't diving into a deep,
> deep hole, I don't strongly object.  Just let me know what to add.

Well, my review amounted to about 5 pages of ordinary text, and my
follow-up e-mail about a page and a half.  If I was unclear regarding
what I thought should be done to make the document clearer to the
unsophisticated reader, please get back to me so that I can improve my
review style.

Dale