Subject: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary?

From: Kurt Andersen <[email-masked]>
Date: Thu, 18 Apr 2019 12:45:42 -0700

If we have a boundary that is 6 names deep in the DNS hierarchy (so the org
domain would be 7 names long), then what is a DMARC validator supposed to
do with an email that claims to come from the domain that is only 5 names
long? What happens to the second lookup (org-level)?

Example:

priv-org.psd-a.b.c.d.e.example: If an email comes from
sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-a.b.c.d.e.example, then
lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.priv-org... and the
proposed lookup 3 (for PSD protection) would be _dmarc.psd-a...

If the email comes from b.c.d.e.example, then lookup 1 is _dmarc.b... but
what would lookups 2 and 3 be? skipped?

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Apr 2019 11:43:51 -0400

> what would lookups 2 and 3 be? skipped?

It's an interesting question, since I think may be a hole in DMARC generally, 
but we can fill it, if needed.

I took a look at the non-comment content of the public portion of the PSL to 
get an idea of the scope of this problem.  Here's the distribution of lengths 
of public suffixes:

one: 3077
two: 3821
three: 1986
four: 3

None longer than that, unless I screwed up my script.

Since more than 20% of the currently documented public suffixes are longer 
than two dots, I think this is a use case worth covering, but I don't think 
changes are needed.  In every case I checked, if c.d.e.example is in the PSL, 
then d.e.example, e.example, and example are also listed, so the proposed PSD 
DMARC lookups should succeed just fine in these cases.

The privacy implications of these types of public suffixes are no different 
than the longest public suffix, since we don't know that they are not also 
used for registering non-public organizational domains.

It might be useful to state this as a condition required for PSD DMARC to work 
correctly, so it's documented rather than just a happy coincidence of the 
current PSL implementation.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Apr 2019 09:11:45 -0700

> None longer than that, unless I screwed up my script.

While it may have changed since the days of DBOUND, I recall that there was
at least one hierarchy which had a public --> private --> public -->
private double transition which could make for longer names.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Apr 2019 12:15:42 -0400

> private double transition which could make for longer names.

OK.  I don't think that changes the analysis as long as all the public 
components are listed.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2019 17:24:37 -0400

>get an idea of the scope of this problem.  Here's the distribution of lengths 

I only see 1527 with no dot.  Since there's only 1532 TLDs it's hard to
see where another 1500 could come from.

The other numbers look right.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Apr 2019 22:35:26 -0400

On Friday, April 19, 2019 05:24:37 PM John Levine wrote:
> >I took a look at the non-comment content of the public portion of the PSL
> >to get an idea of the scope of this problem.  Here's the distribution of
> >lengths of public suffixes:
> >
> >one: 3077
> >two: 3821
> >three: 1986
> >four: 3
> 

Thanks.  

My script was counting blank lines (sigh).  Now I get the same result you do.

That raises the three or more percentage over 27%.

Scott K