Re: [dmarc-ietf] draft-ietf-dmarc-psd review

["Murray S. Kucherawy" <[e-mail]>]

Thanks for this, much better.  Some additional feedback.

Please note (everyone) that I'm offering these as clarifying contributions
to text; I'm not prescribing or proscribing anything.  If the text I'm
proposing isn't worthy of consensus, please speak up.

On Sat, Jul 27, 2019 at 1:45 PM Scott Kitterman <[e-mail]>
wrote:

>
> I updated the paragraph to start:
>
>    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.  DMARC policies can be
>    applied to individual domains or to all domains within an
>    organization.  The design of DMARC precludes grouping policies for
>    domains based on policy published above the organizational level,
>    such as TLDs (Top Level Domains).
>
> Does that clear those comments up?
>

That last sentence still puzzles me, and I think it's the term "grouping"
that gives me trouble.

How's this?

   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 the Public Suffix List (PSL) to be ineligible for DMARC enforcement.


If we like this, I suggest it or language like it can also be used to
rework the first paragraph of the Introduction section in -05.  To
import DMARC definitions into the introduction, you could say that
DMARC presumes that a domain is either on the PSL or is an OD, and
never both,.


> >    As an example, imagine a country code TLD (ccTLD) which has public
> >    subdomains for government and commercial use (.gov.example and
> >    .com.example).  Within the .gov.example public suffix, use of DMARC
> >    [RFC7489] has been mandated and .gov.example has published its own
> >    DMARC [RFC7489] record:
> >
> >    "v=DMARC1;p=reject;rua=mailto:[e-mail]"
> >
> > Can we add spaces after the semicolons? I know this is legal format
> > but it would be more readable.
>
> Changed.
>

Thanks.  Now for the text right before the example; I suggest:

As an example, ...  Suppose there exists a registered domain
"tax.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
"t4x.gov.example".  These domains are not registered.  Within the
".gov.example" public suffix, use of DMARC has been mandated, so
"gov.example" publishes the following DMARC record:

...

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.


> >    There are two types of Public Suffix Operators (PSOs) for which this
> >    extension would be useful and appropriate:
> >
> >    o  Branded PSDs (e.g., ".google"): These domains are effectively
> >       Organizational Domains as discussed in DMARC [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 [RFC7489] purposes.  They require the same
> >       protections as DMARC [RFC7489] Organizational Domains, but are
> >       currently excluded.
> >
> > How are they current excluded?  Is this because they're on the PSL, so
> > DMARC treats them differently?
>
> Yes.  Per the DMARC definition, they are not organizational domains.
>

I suggest "unable to benefit from DMARC" rather than "excluded".
"Excluded" makes me think DMARC specifically targeted them as not worthy of
or appropriate for inclusion, which isn't the case.


> >    o  Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
> >       Because existing Organizational Domains using this PSD have their
> >       own DMARC policy, the applicability of this extension is for non-
> >       existent domains.  The extension allows the brand protection
> >       benefits of DMARC [RFC7489] to extend to the entire PSD, including
> >       cousin domains of registered organizations.
> >
> > An example would be useful here.
>
> I've added this:
>
>    As an example, take the ".gov.example" described above and add that
>    for this entity emails about tax returns are sent from
>    tax.gov.example.  It would not be surprising if fraudulent emails
>    were sent purporting to be from taxes.gov.example (taxes is a cousin
>    of tax - different enough to evade DMARC protection, but similar
>    enough to potentially confuse users).  As defined in DMARC [RFC7489],
>    a DMARC record could be published for tax.gov.example, but there is
>    no general solution to publishing a DMARC policy to defend against
>    abuse of non-existent cousins such as taxes.gov.example.  While an
>    explicit record could be published for this one domain, the universe
>    of possible cousins is such that this approach does not scale.
>
> How's that?
>

Great, and it's also pretty much what I proposed above.  (Apologies; my
read-ahead failed.)  I suggest picking one or the other, but I think it's
of benefit to put this higher up where my suggestion is to set context.

>    Due to the design of DMARC [RFC7489] and the nature of the Internet
> >    email architecture [RFC5598], there are interoperability issues
> >    associated with DMARC [RFC7489] deployment.  These are discussed in
> >    Interoperability Issues between DMARC and Indirect Email Flows
> >    [RFC7960].  These issues are not applicable to PSDs, since they
> >    (e.g., the ".gov.example" used above) do not send mail.
> >
> > DMARC doesn't need to be followed by its RFC number every time.
>
> I went through and removed most of these.  I tried to remove them so that
> it's
> mostly there when talking about DMARC the RFC, not DMARC the protocol.
>

Yeah I think you got most of them but there are a few I would still
reduce.  Not a big deal unless others concur; the RFC Editor will probably
chime in as well.

> 2.2.  Public Suffix Domain (PSD)
> >
> >    The global Internet Domain Name System (DNS) is documented in
> >    numerous Requests for Comment (RFC).  It defines a tree of names
> >    starting with root, ".", immediately below which are Top Level Domain
> >    names such as ".com" and ".us".  They are not available for private
> >    registration.  In many cases the public portion of the DNS tree is
> >    more than one level deep.  PSD DMARC includes all public domains
> >    above the organizational level in the tree, e.g., ".gov.uk".
> >
> > I don't know what that last sentence means.  PSD DMARC is an
> > extension; how does it include domains?
>
> Deleted the sentence.  I don't think it is necessary for the definition,
> so
> let's not confuse things.
>

The text present now for 2.2 defines the name/label structure of the DNS,
but doesn't actually say what a PSD is.

This is an interesting problem, because we are attempting to describe (or
ascribe) semantics of the DNS that simply do not exist.  The DNS is a
hierarchical naming structure and related database, plain and simple; we
are attempting to ascribe to it boundaries that are not there in DNS-land.
But we happen to do lookups in it using DNS APIs.

So let's try removing the DNS from the definition:

The domain name structure consists of a tree of names, each of which is
made of a sequence of words ("labels") separated by period characters.  The
root of the tree is simply called ".".  The Internet community at large,
through processes and policies external to this work, selects points in
this tree at which to register domain names "owned" by independent
organizations.  Real-world examples are ".com", ".org", ".us", and ".gov.uk".
Names at which such registrations occur are called Public Suffix Domains
(PSDs), and a registration consists of a label selected by the registrant
to which a desirable PSD is appended.  For example, "ietf.org" is a
registered domain name, and ".org" is its PSD.

While I'm here, I suggest 2.3 is a little terse.  Maybe:

The longest PSD is the PSD matching more labels in the domain name under
evaluation than any other PSL entry.

> 3.2.  Section 6.1 DMARC Policy Record
> >
> >    PSD DMARC records are published as a subdomain of the PSD.  For the
> >    PSD ".example", the PSO would post DMARC policy in a TXT record at
> >    "_dmarc.example".
> >
> > Don't you mean the PSD DMARC record is a record in the zone of the
> > PSD?  It's not a subdomain.
>
> Here's what's in RFC 7489 about DMARC record publishing:
>
> 6.1.  DMARC Policy Record
>
>    Domain Owner DMARC preferences are stored as DNS TXT records in
>    subdomains named "_dmarc".  For example, the Domain Owner of
>    "example.com" would post DMARC preferences in a TXT record at
>    "_dmarc.example.com".
>
> I think our 3.2 is equivalent and adequate given this section is a
> modification
> to RFC 7489 Section 6.1.  I did not make a change.
>

Embarrassing.  RFC7489 6.1's text you cited is unfortunate.  I would change
"in subdomains named" to "at labels named".

But also, why do we need this section?  The PSD DMARC record is in the same
place as one would expect it having read only RFC7489, correct?

> 3.4.  Section 6.6.3.  Policy Discovery
> >
> >    A new step between step 3 and 4 is added:
> >
> >    3A.  If the set is now empty and the longest PSD (Section 2.3) of the
> >       Organizational Domain is one that the receiver has determined is
> >       acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
> >       a DMARC TXT record at the DNS domain matching the longest PSD
> >       (Section 2.3) in place of the RFC5322.From domain in the message
> >       (if different).  A possibly empty set of records is returned.
> >
> > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I
> > don't know what "acceptable for PSD DMARC" might mean.
>
> Changed to:
>
>    3A.  If the set is now empty and the longest PSD (Section 2.3) of the
>       Organizational Domain is one that the receiver has determined is
>       acceptable for PSD DMARC (discussed in the experiment description
>       (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC
>       TXT record at the DNS domain matching the longest PSD
>       (Section 2.3) in place of the RFC5322.From domain in the message
>       (if different).  A possibly empty set of records is returned.
>
> > Section numbers in the prose of this section should make clear which
> > document they're referencing.
>
> I checked and any reference to an RFC7489 paragraph number that's in the
> text
> is labeled as such.


I'm talking about the "Section 2.3" here, and the "Section x.y" strings in
the section headings in Section 3.  Since you are pointing back to RFC7489
frequently, I thought it might be best to say "Section 2.3 of this
document", or "Section x.y of RFC7489", as appropriate.

Also in the example in the paragraph below here in the document, you're
using ".cctld"; should that be ".example" or ".cctld.example"?

One final thing: I added a sentence at the end of my proposed Abstract that
tries to highlight that domains on the PSL also need to be checked and not
special-cased when one receives mail from a PSL.  In order to tie it to the
experiment, I suggest this (as a new section at the end; reorder at your
discretion):

3.7.  PSDs Are Eligible For DMARC

Experience with DMARC has shown that some implementations short-circuit
messages, bypassing DMARC policy application, when the domain name
extracted by the receiver (from the RFC5322.From) is on the PSL.  This
prevents the capability being created by this specification.  Therefore,
the following paragraph is appended to Section 6.6.1 of RFC7489:

Note that domain names that appear on the Public Suffix List are not exempt
from DMARC policy application and reporting.

-MSK