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

From: Scott Kitterman <[email-masked]>
Date: Sun, 13 Jan 2019 19:19:39 -0500

This update removes the IANA registry (which is what I think I was supposed to 
do based on the feedback to date).  I also bulked up the Privacy/Security 
considerations descriptions since they are no longer mitigated.

I'd like feedback on the best path forward.  Essentially this draft replaces 
the IANA registry with an undefined way to know where PSD DMARC is 
appropriate.  I think we need something better than that, but I didn't know 
what.

Suggestions please.

Scott K

----------  Forwarded Message  ----------

Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-01.txt
Date: Sunday, January 13, 2019, 04:16:03 PM
From: [email-masked]
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           : DMARC (Domain-based Message Authentication, 
Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
        Author          : Scott Kitterman
	Filename        : draft-ietf-dmarc-psd-01.txt
	Pages           : 9
	Date            : 2019-01-13

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.  DMARC policies can be
   applied at the individual domain level or for a set of domains at the
   organizational level.  The design of DMARC precludes grouping
   policies for a set of domains above the organizational level, such as
   TLDs (Top Level Domains).  These types of domains (which are not all
   at the top level of the DNS tree) can be collectively referred to as
   Public Suffix Domains (PSDs).  For the subset of PSDs that require
   DMARC usage, this memo describes an extension to DMARC to enable
   DMARC functionality for such domains.

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

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

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/

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

-----------------------------------------

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2019 19:49:17 -0500

>appropriate.  I think we need something better than that, but I didn't know 

The more I look at this, the less I understand what problem it solves.
If you manage a zone that can publish a PSD policy, you have some kind
of relationship with the zone members so you should be auditing their
policies anyway.

To take a non-random example, I looked at the 2700 names in .BANK.
There are 122 with no DMARC at all, which PSD might help, but there
are also 164 with p=none, 29 with p=quarantine, 7 with pct=N where N
is not 100, 4 with multiple policies, and about 30 where the DMARC
record is invalid.  Assuming your goal is to get everyone to p=none,
PSD doesn't impress me as offering significant help.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Jan 2019 00:43:32 -0500

On Tuesday, January 15, 2019 07:49:17 PM John Levine wrote:
> >This update removes the IANA registry (which is what I think I was supposed
> >to do based on the feedback to date).  I also bulked up the
> >Privacy/Security considerations descriptions since they are no longer
> >mitigated.
> >
> >I'd like feedback on the best path forward.  Essentially this draft
> >replaces the IANA registry with an undefined way to know where PSD DMARC
> >is appropriate.  I think we need something better than that, but I didn't
> >know what.
> 

My understanding is that, since, as you say, PSOs (like .bank) have a pre-
existing relationship with their registrants, they don't need PSD DMARC to 
audit their registrant's policies.  For an entity like that, it offers the 
chance to get feedback on other, presumably non-existent, domains so as to 
better understand abuse patterns within the PSD they manage.  It also gives 
them a mechanism to express a reject policy for those domains, which does not 
currently exist.  This may help improve rejection of cousin domains by 
receivers.

For single entity PSDs, like for a very large Internet company that is, 
conveniently not named after a large South American rain forest (so they can 
get it registered), it offers other advantages.  In cases like this, the PSD 
operates like an organizational domain except for the fact that in the current 
DMARC instantiation, their record won't work for subdomains.  PSD DMARC would 
enable '.example' to publish a single record for all lower level entries in 
the zone.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 17 Jan 2019 13:50:18 -0500

>enable '.example' to publish a single record for all lower level entries in 

That all seems reasonable but it still feels like a lot of mechanism for
marginial benefit, particularly since we have no clue who's going to run it
if we can't foist it off on Mozilla.

I wonder if there's any way to get the PSL to tag vanity TLDs.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Thu, 17 Jan 2019 11:25:33 -0800

> I wonder if there's any way to get the PSL to tag vanity TLDs.

I believe a single list is the best long term solution. It just needs the
domain and two flags, one for if the domain is a public suffix, and the
other is if its a public suffix domain (per this draft).

For instance;

domain          | PS | PSD
---------------------------------
.co.uk           | true | false
.gov.uk          | true | true
.brand           | false | true

This seems to adequately cover all uses cases described (with the .co.uk
example being the state of everything currently on the PSL), is simple, and
in one place.

I think the primary question (before we go down the PSL/Mozilla rabbit
hole) is what the proper technical solution is - one list, multiple lists,
no list.

After clarity on that, then we can dig into how and where this thing lives.

Seth

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 17 Jan 2019 12:40:55 -0800

What is the difference between a PS vs a PSD in your statement? For the DNS
a record is a record is a record.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Thu, 17 Jan 2019 12:58:23 -0800

On Thu, Jan 17, 2019 at 12:41 PM Kurt Andersen <[email-masked]> wrote:

> What is the difference between a PS vs a PSD in your statement? For the
> DNS a record is a record is a record.
>

Specifically, there are some domains (like .brand in my example) that
should be capable of being used as an organizational domain but are not
public suffixes themselves. This is exactly what "branded PSD" in
https://tools.ietf.org/html/draft-ietf-dmarc-psd-01#section-1 refers to.

Without this distinction, these domains don't make sense on a list of
public suffixes like the PSL. If we're going to have one list that
enumerate both public suffixes and public suffix domains, then this
distinction is critical for the branded PSD use case.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Jan 2019 04:14:42 -0500

On Thursday, January 17, 2019 01:50:18 PM John Levine wrote:
> >them a mechanism to express a reject policy for those domains, which does
> >not currently exist.  This may help improve rejection of cousin domains by
> >receivers.
> >
> >conveniently not named after a large South American rain forest (so they
> >can get it registered), it offers other advantages.  In cases like this,
> >the PSD operates like an organizational domain except for the fact that in
> >the current DMARC instantiation, their record won't work for subdomains. 
> >PSD DMARC would enable '.example' to publish a single record for all lower
> >level entries in the zone.
> 

There are two parts to the PSL; a section called "ICANN DOMAINS" and another 
called "PRIVATE DOMAINS".  All the TLDs (single user or not) are in the ICANN 
DOMAINS section.

I don't know if it would be enough to have them also listed in PRIVATE 
DOMAINS.  I don't expect they would want to remove them from ICANN DOMAINS, 
since that's not wrong, it just doesn't fit out use case.

It would require some adjustments to the current DMARC algorithm for 
organizational domain identification.  

The current process is to take the 2822.From domain and (assuming there is no 
DMARC record for that domain) look-up in the PSL and reduce the 2822.From 
domain to the PSL ICANN DOMAIN + one level.  If that level has no DMARC 
record, then the domain does not participate in DMARC.

If Mozilla would add these single user TLDs to the PRIVATE DOMAINS section 
also, we could adjust this slightly and for this use case (which is only one 
of three in the draft) it would work:

After checking PSL ICANN DOMAIN + one level, if there is no DMARC record, then 
check the PSL PRIVATE DOMAIN list and if the domain is listed there, check for 
a DMARC record.

I don't know that this would violate the sematics of the PSL and they are, in 
fact, both ICANN domains and private.  Based on the description at 
https://publicsuffix.org/list/ it seems like it might be accepted.

Regardless of exactly how we do this for PSD DMARC, it is probably work 
documenting that for DMARC (the regular kind), only the ICANN domain section 
of the PSL is used.

Does anyone know someone at Mozilla to ask?

For the other, non-single user domains, maybe the best we can do is an 
appendix that describes the characteristics of PSDs for which PSD DMARC checks 
are suitable and lists our three from the initial registry as examples.  
Otherwise, I think we need a new list somewhere because those (like .bank) are 
clearly not private.  If IANA is not the right place to host a list, does 
anyone have any other suggestions for the ones that won't work on the PSL?

Scott K