Subject: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Nov 2018 02:37:19 -0500

While we were discussing making draft-kitterman-dmarc-psd a working group 
item, the main discussion point was about the use of an IANA registry to 
identify participating public suffix domains.  I think it would be useful to 
consider what problems we were trying to solve and see if there are 
alternative approaches that address those requirements.

Also, while I think the discussion about a DMARC specific public boundary 
discovery mechanism was useful, and we should consider taking on that work, I 
think it's not closely coupled to Public Suffix Domains and should be 
discussed as a separate work item.

Goals:

1.  Minimize additional verifier burden for adding PSD DMARC support.  
Currently it requires consulting a locally stored, infrequently changing list 
and one additional DNS lookup only for participating public suffixes when 
there is no organizational domain DMARC record.

2.  Externalize signaling about PSD participation.  As discussed in the 
Privacy Considerations (section 4.1), we were concerned about the privacy 
implications of feedback on organizational domain traffic for organizational 
domains that don't participate in DMARC being inappropriately captured by 
public suffix operators.  In order to avoid this, we identified criteria for 
which public suffixes PSD DMARC would be appropriate for and require an 
external review to ensure those criteria are met.  No solution that's in DNS 
will address this part of the problem.

I believe that if there are alternatives that support both these requirements, 
then they should be seriously considered, we just didn't think of one when 
working up the draft.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Nov 2018 18:20:52 +0100

On Wed 21/Nov/2018 08:37:19 +0100 Scott Kitterman wrote:

> [...]

/DMARC specific public boundary discovery/ is still ambiguous.  Given the
nature of the I-D, we are splitting the concept of boundary into two types:

1. *Alignment* which defines sets of shared responsibility, and

2. *Policing and reporting* which defines sets of shared criteria.

Type #1 is a refinement of #2.  For example, all banks may wish to share a
secure policy and possibly a common surveillance method.  However, they don't
necessarily share customer accounts (let me recall that sharing session cookies
implies just that.)

> there is no organizational domain DMARC record.

Browsing a copy of the PSL, I found just 17 entries with 5 labels, like:
s3.cn-north-1.amazonaws.com.cn and
app.os.stg.fedoraproject.org

Querying each subdomain would require 4 extra lookups.  How much do we save in
a dbound-like scenario?  What about organizations that have not yet published
boundary information?  How about the camel[*]?

[*] https://ietf.org/blog/herding-dns-camel/

> will address this part of the problem.

I'm not clear what kind of inappropriateness is implied here.  The overwhelming
majority of people is pretty comfortable with having their personal stuff
stored in "Echelon".  Yet, if a domain is uncomfortable with the policy in
_dmarc.com, it can opt out by publishing its own record.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Nov 2018 02:20:50 -0500

On Thursday, November 22, 2018 06:20:52 PM Alessandro Vesely wrote:
> > discovery mechanism was useful, and we should consider taking on that
> > work, I think it's not closely coupled to Public Suffix Domains and
> > should be discussed as a separate work item.
> 
> secure policy and possibly a common surveillance method.  However, they
> don't necessarily share customer accounts (let me recall that sharing
> session cookies implies just that.)

I'd suggest having the argument about if PSL is good enough or if we need a 
mechanism in DNS in a separate thread (which is why I wrote another mail to 
discuss that very topic).  There's nothing in this draft about defining where 
the boundary is (just as in DMARC itself).

> > Currently it requires consulting a locally stored, infrequently changing
> > list and one additional DNS lookup only for participating public suffixes
> > when there is no organizational domain DMARC record.
> 
> Querying each subdomain would require 4 extra lookups.  How much do we save
> in a dbound-like scenario?  What about organizations that have not yet
> published boundary information?  How about the camel[*]?

No.  There's nothing in the draft about walking up a tree.  The draft looks 
one label higher in the tree than the organizational domain, that's it.  One 
and only one is the maximum additional number of lookups in the current draft.

I've no idea how a DNS indication of the boundary would help or hurt these 
cases, but it's orthogonal to the subject of this message.

> [*] https://ietf.org/blog/herding-dns-camel/

I'm not sure why you even mention this since the draft proposes no new DNS 
functionality.

> > implications of feedback on organizational domain traffic for
> > organizational domains that don't participate in DMARC being
> > inappropriately captured by public suffix operators.  In order to avoid
> > this, we identified criteria for which public suffixes PSD DMARC would be
> > appropriate for and require an external review to ensure those criteria
> > are met.  No solution that's in DNS will address this part of the
> > problem.
> 
> I'm not clear what kind of inappropriateness is implied here.  The
> overwhelming majority of people is pretty comfortable with having their
> personal stuff stored in "Echelon".  Yet, if a domain is uncomfortable with
> the policy in _dmarc.com, it can opt out by publishing its own record.

That's exactly backwards and the reason I wrote the privacy considerations.  
It's also completely contrary to IETF policy on the subject, see RFC 7258/BCP 
188 [1].

During the adoption discussions there was some concern with the registry 
approach used so far.  I would really like to have a discussion on 
alternatives.  Personally, I don't think it's very useful to spend working 
group time on if privacy matters.

Scott K

[1] https://tools.ietf.org/rfc/rfc7258.txt

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Nov 2018 13:17:41 +0100

On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
> 
> [...]  There's nothing in the draft about walking up a tree.  The draft looks 

That sounds acceptable to me.  I don't think one extra query is going to have a
tremendous impact:

DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since that
is required for sending aggregate reports.  The availability of such a database
makes it handy to store parsed policies as well.  That is to say, a well
designed mail filter can cache DNS data directly.  Hence, given a decent SOA
TTL, that extra lookup can probably be skipped on most messages.  Compared to
the amount of per-message DNS queries, it doesn't seem to hurt.

DMARC could have a better say on implied TTLs, since data seen at lookup time
is going to be reported at end-of-day time.

> cases, but it's orthogonal to the subject of this message.

Neither do I.

> I'm not sure why you even mention this since the draft proposes no new DNS 

I had read about instructive re-readings of DBOUND in previous discussions on
this subject, so it seemed worth to consider the camel load.

> It's also completely contrary to IETF policy on the subject, see RFC 7258/BCP 

Agreed.  Rfc7489 misses an analysis of the risk implied by feedback reports,
except for mentioning that ruf targets receive more privacy-sensible data than
rua's (Section 12.5).  Your I-D discourages ruf tags in PSD DMARC records, so
that's partly addressed.

Your I-D says some PSDs can impose a default DMARC policy while others cannot,
but doesn't mention a rule to tell which is which.  Yes, it mentions a IANA
registry, but then it is not clear what rules or principles the designated
expert would consider adequate.  The case that all domain owners are part of a
single organization with the PSO would rather seem to be an error of the PSL.

> group time on if privacy matters.

Right, the consensus is that privacy matters.  In rfc7258's words, we need to
have a good answer to the question "Is pervasive monitoring relevant to this
work and if so, how has it been considered?"  Unless we do the same for all
PSDs, a good answer should also explain PSDs differences a little bit better
than the current I-D does, which seems to be another hairy question.

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 23 Nov 2018 11:57:20 -0500

> is going to be reported at end-of-day time.
I remember chatting with John Levine about this maybe six month ago about
ARC and DNS
lookups and he said "the extra DNS lookups should not be an issue" which I
agreed with.
Since I do DNS Operations for a mid-sized SaaS vendor, and we play lots of
SOA/TTL games
(10s NXTTL, 300s TTLs for most records, etc)  I went and looked at our DNS
query
usage around our SPF records as an example (since we do layered SPF), and
those
queries barely scratch the top 25, but the DMARC/DKIM queries are way down
in the noise.
I can't see where a second query is an issue, as long as the applications
are
fine in doing them.

Tim

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Nov 2018 16:09:46 -0500

> On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
... 
> > It's also completely contrary to IETF policy on the subject, see RFC
> > 7258/BCP 188 [1].
> 
> except for mentioning that ruf targets receive more privacy-sensible data
> than rua's (Section 12.5).  Your I-D discourages ruf tags in PSD DMARC
> records, so that's partly addressed.
> 
> Your I-D says some PSDs can impose a default DMARC policy while others
> cannot, but doesn't mention a rule to tell which is which.  Yes, it
> mentions a IANA registry, but then it is not clear what rules or principles
> the designated expert would consider adequate.  The case that all domain
> owners are part of a single organization with the PSO would rather seem to
> be an error of the PSL.

The problem is that there is no generic rule to cover all cases, ccTLDs, 
generic TLDs, and legacy TLDs all have different rules (and different rules 
within each of those groups).  That's why we designate an expert to figure it 
out.  Typically (as far as I can tell) RFCs that use designated experts for 
IANA registry review only give very general guidance.  The guidance here is, I 
think, appropriate (DMARC use is required for private domains registered in 
the PSD/TLD).

Arguing the PSL is wrong, isn't really helpful for this use case.  Even if the 
PSL were fixed/replaced by some dbound type thing, that would only affect the 
single use TLD case (so we delete a handful of lines from the draft).  They 
are the simplest case.

I think we should focus on the mechanism to allow for "above org level" DMARC 
checks (which is what this draft does) that is limited in scope so that 
registrars can't conduct an inappropriate land grab.  It's not like this kind 
of thing hasn't happened before [1].

[1] https://www.theregister.co.uk/2003/09/16/all_your_web_typos/

> Right, the consensus is that privacy matters.  In rfc7258's words, we need
> to have a good answer to the question "Is pervasive monitoring relevant to
> this work and if so, how has it been considered?"  Unless we do the same
> for all PSDs, a good answer should also explain PSDs differences a little
> bit better than the current I-D does, which seems to be another hairy
> question.

I am open to suggestions.

Scott K

---

From: Zeke Hendrickson <[email-masked]>
Date: Fri, 30 Nov 2018 21:40:33 +0000

> will address this part of the problem.

I feel that restricting the additional PSD check to nonexistent
organizational domains is the best approach, as it preserves the
opt-in nature of DMARC, limits privacy concerns, remains very
straightforward to implement as a verifier, and does not rely on an
additional list.

draft-ietf-dmarc-psd-00 addresses a slightly broader problem space,
but I feel that adding the ability to get feedback on abuse of
nonexistent domains is the most needed aspect; treating branded PSDs
as organizational domains would be better addressed by improving the
way organizational boundaries are determined.

-- 
Zeke Hendrickson ([email-masked])
University of Michigan | Information and Technology Services
Infrastructure | Application Operations | Collaboration Services

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 30 Nov 2018 14:52:04 -0800

On Fri, Nov 30, 2018 at 1:40 PM Zeke Hendrickson <[email-masked]> wrote:

> organizational domains is the best approach,

I disagree...see below

> as it preserves the opt-in nature of DMARC,

granted

> limits privacy concerns,

No - this is the very essence of the need for a controlled registry of LPS
(longest public suffix) to be checked. It's
easy for a human to mistype a domain name and that could result in a report
to the LPS's RUA.

> remains very straightforward to implement as a verifier, and does not rely
> on an
> additional list.
>

Agreed, but the downside is high.

> draft-ietf-dmarc-psd-00 addresses a slightly broader problem space

Yes, and it is an important additional area to cover IMO

--Kurt Andersen

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 Nov 2018 23:37:24 +0000

On November 30, 2018 9:40:33 PM UTC, Zeke Hendrickson <[email-masked]> wrote:
>organizational 

RFC 7489 (DMARC) Appendix A.4 mentions that a domain existence test was tried and abandoned as unreliable.  Before reconsidering that kind of approach, it would be important to understand the limitations that caused it to be discarded before.

As Kurt mentioned, I don't think it solves the registry problem in any case because I don't think wide open TLDs like .com ought to be stimulating feedback on any lower level elements of the DNS tree.

>way organizational boundaries are determined.

Currently we have no mechanism at all for that, so I'd be reluctant to abandon the use case in favor of a non-existent solution.

Also, I think a formal non-existence test would require additional DNS lookups and might not even be simpler to implement.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2018 19:33:00 -0500

In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
>public suffix operators.

It seems to me this horse left the barn a long time ago.  Mail systems
routinely check domains in HELO and in MAIL FROM against DNSBLs, which
is at least as loggy as anything a DNS version of this check will do.

Also, if you really want to keep people from logging your queries, you
can set up a local mirror of the DNS zone, and update it in the usual
way with AXFR and IXFR.  Whatever one might have in mind for a text
version of this, a binary AXFR would be about as fast and IXFR of just
the occasional change faster.

Take a look at my DBOUND proposal.  I think it would be just the
ticket for this application.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 Nov 2018 20:04:04 -0500

On Friday, November 30, 2018 07:33:00 PM John Levine wrote:
> >inappropriately captured by public suffix operators.
> 

I've lost track.  Which draft was that?

I don't agree that a situation being bad is a reasonable reason not to try and 
keep it from getting worse.  I think the implications of the DMARC feedback 
reports are greater than logging queries.

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 30 Nov 2018 20:06:17 -0500

https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt

On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman <[email-masked]>
wrote:

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

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Dec 2018 01:27:54 +0000

Thanks.  That refreshes my memory.

I think it's a proposal that has potential to be an eventual standardized replacement for using the public suffix and we should look into publishing a DMARC specific variation.

It doesn't, however, seem to address the issue described in the draft's privacy considerations.

Perhaps we need to step back and see if there is consensus that the privacy considerations in the draft are substantially correct and if risk mitigation is needed as described.

Scott K

On December 1, 2018 1:06:17 AM UTC, Tim Wicinski <[email-masked]> wrote:
>> I don't agree that a situation being bad is a reasonable reason not
>to try
>> and