Subject: [dmarc-ietf] PSD simplification

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2018 20:17:38 -0800

Folks,

Howdy.

This note is the result of some offline discussions, patiently helping 
me to work through the purpose of the kitterman-dmarc-psd.  After some 
false starts, here's where I landed:

I believe the registry created by kitterman-dmarc-psd is not needed. 
More generally I believe the proposal spec can be considerably abbreviated.

     1.  If the registry is to constrain which public suffix operators 
are constrained to assert a default record, then I'll claim that's a 
false sense of security, given the range of unrelated and even more 
serious powers a parent domain can exert over a subordinate one.

     2.  If it is to avoid wasting a DNS a query to a record that won't 
be there, that's false economy.  Most queries to the registry will fail. 
   And most queries to both the From: domain name and its organizational 
domain already fail. The incremental cost of a wasted query to the 
organizational domain's parent is pretty small.

And the cost of creating and running a query-able database that is kept 
current is high and error-prone (as the existing PSL demonstrates.)

So I think that the functional goal of kitterman-dmarc-psd is fully 
satisfied by merely doing a version of the 3A update to DMARC, directing 
the client to query the immediate parent of the organizational domain, 
if the OD has been queried and no DMARC record has been found.

That is, making DMARC have a 3-level lookup sequence rather than two, 
where the additional one is the same as for the organizational domain, 
except one level higher.

Thoughts?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Dec 2018 00:01:47 -0500

> where the additional one is the same as for the organizational domain,

I think your analysis is essentially correct, but I think point 1 is 
backwards.  Since (in the current draft), based on the registry entries, the 
third level queries will usually not take place. It's not that the PSOs are 
constrained not to publish records (they aren't), it's that no one will 
(should) query for them based on the third level test if they aren't in the 
registry.

This may seem like a small thing, but I believe it makes all the difference.  
You are certainly correct that nothing in an RFC can prevent a PSO from 
publishing such records.  What we can do is give guidance on when not to look 
at them.

I believe avoiding the privacy implications of the related feedback are worth 
the transactional costs of the registry (but then I would, wouldn't I).  I 
don't think a bad situation justifies making it worse.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Dec 2018 07:30:20 -0800

>> are constrained to assert a default record, then I'll claim that's
>> a false sense of security, given the range of unrelated and even
>> more serious powers a parent domain can exert over a subordinate
>> one.
>> 
>> be there, that's false economy.  Most queries to the registry will
>> fail. And most queries to both the From: domain name and its
>> organizational domain already fail. The incremental cost of a
>> wasted query to the organizational domain's parent is pretty
>> small.
>> 
>> And the cost of creating and running a query-able database that is
>> kept current is high and error-prone (as the existing PSL
>> demonstrates.)
...

> backwards.  Since (in the current draft), based on the registry
> entries, the third level queries will usually not take place. It's
> not that the PSOs are constrained not to publish records (they
> aren't), it's that no one will (should) query for them based on the
> third level test if they aren't in the registry.
> 

That's a cost-saving line of concern.  My point is that the existing
mechanism already has quite a bit operational inefficiency from queries
that fail, so that adding one more is a minor issue, especially as
against the considerable administrative and operational cost of creating
and running a registry.

> I believe avoiding the privacy implications of the related feedback
> are worth the transactional costs of the registry (but then I would,
> wouldn't I).  I don't think a bad situation justifies making it
> worse.

Sorry but I don't know what privacy implications you are referring to.
I don't even have a guess.

And the draft makes no reference to privacy issues.  Or rather, the 
Privacy Considerations section says the draft doesn't introduce any.

d/

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2018 11:59:13 -0500

>if the OD has been queried and no DMARC record has been found.

Given that anything we do to handle public suffix defaults will need
some code changes, this seems about the simplest change that would do
the trick.

I am aware of two security or privacy issues that might come up.  If
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names.  This approach doesn't have that problem.
The DNS operator can tell that someone is asking about a subdomain,
but not which subdomain.

The other is that the DMARC record might have rua= and ruf= and get
detailed reports about subdomains.  This is not an unreasonable concern --
I am the legacy registrar for various <geographic>.ny.us domains and
my DMARC reports tell me a lot about one of my registrants who sends
a lot of mail.  (Real mail, they're the county govermnent.)  This is
easily addressed by clients ignoring the report advice in the OD
parent record.

One issue that is not our problem but might be Scott's is that in
ICANN contracted TLDs, they're not allowed to publish TXT records at
_dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
permission to do so.  I happen to know the people who evaluate the
applications (as do many other people here) and I'm sure they would
say yes for those two TLDs, but it would involve some time and money.
This might actually be a feature, since a similar appplication for
_dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
scepticism.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Dec 2018 09:38:10 -0800

> traffic from various names.  This approach doesn't have that problem.

1. Doesn't the query to the registry suffer the same risk?

2. I'm not sure what a "DNS policy server" is.  I'm guessing it's meant 
as a DNS server that contains the dbound-ish records?

3. Given queries for MX record, don't we already have massive exposure 
of this privacy-related info in DNS activity?  How would this be so much 
more (and/or worse)?

 > The DNS operator can tell that someone is asking about a subdomain,

Sorry but I don't understand this.  A bout of densitude has enveloped 
me.  Please explain, pedantically.

> easily addressed by clients ignoring the report advice in the OD

What does it mean for a /client/ to ignore the advice in the OD parent 
record?  I thought that record was for servers.

I'm now guessing that your note is primarily (or completely) about the 
basic, potential dangers of having a default DMARC record in a public 
registry, rather than being about the refinements to the PSD spec I've 
suggested?

> _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more

This invites an exercise at writing a policy directive to characterize 
the types of TLDs that are good candidates for saying yes and those that 
are good candidates for saying no.  The most useful part of such a 
document would be charactizing 'types' of registries...

d/

---

From: "John R Levine" <[email-masked]>
Date: 12 Dec 2018 12:47:16 -0500

On Wed, 12 Dec 2018, Dave Crocker wrote:
> 2. I'm not sure what a "DNS policy server" is.  I'm guessing it's meant as a 
> DNS server that contains the dbound-ish records?

For #2, that's right.  For #1, my DBOUND scheme does a lookup which 
includes the full name, e,g, if you're checking the boundary for 
foo.bar.com it looks up foo.bar._dbound.com.  It will likely be 
matched by a wildcard *._dbound.com, but the query's in the logs.  With 
your scheme it just looks up _dmarc.com.

> 3. Given queries for MX record, don't we already have massive exposure of 
> this privacy-related info in DNS activity?  How would this be so much more 
> (and/or worse)?

Particularly with large passive DNS databases, you're right.  I believe 
that Scott's point was that we can try not to make it worse.

> record?  I thought that record was for servers.

I meant the DNS client, which is likely to be the mail server receiving a 
message.

> This invites an exercise at writing a policy directive to characterize the 
> types of TLDs that are good candidates for saying yes and those that are good 
> candidates for saying no.  The most useful part of such a document would be 
> charactizing 'types' of registries...

That's already done.  Some limit registrations to identified members of a 
community, some don't.  You can argue how well those limits are enforced 
(what am I doing with names in .aero and .travel?) but the principle is 
clear enough.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Dec 2018 09:59:59 -0800

On 12/12/2018 9:47 AM, John R Levine wrote:
>> of this privacy-related info in DNS activity?  How would this be so 
>> much more (and/or worse)?
> 

This is a point worth pressing on.  Hard.

The source of the pressure is that the cost of a queriable registry is 
high.  Very, very high.  So creating one needs to have a very compelling 
justification.  I don't see how this one comes close.

> I meant the DNS client, which is likely to be the mail server receiving 
> a message.

Besides retrieving information and passing it up to its caller, the DNS 
client has nothing at all to do with using advice in an OD parent 
record.  Hence my confusion about your text.  So I think you meant "This 
is easily addressed by receivers ignoring the report adivce in the OD 
parent record."

Contrary to many other occasions, I'm not being this picky just for fun. 
  These topics seem to engender confusion in lots of folk and lots of 
discussions, and so I think it important to be very careful about 
terminology and references.

d/

---

From: "John R Levine" <[email-masked]>
Date: 12 Dec 2018 13:45:48 -0500

On Wed, 12 Dec 2018, Dave Crocker wrote:
> The source of the pressure is that the cost of a queriable registry is high. 
> Very, very high.  So creating one needs to have a very compelling 

Seems that way to me.  Even if it's distributed by DNS, perhaps under 
blah.psd.arpa, so it uses existing infrastructure, it's still significant 
work to manage.

> client has nothing at all to do with using advice in an OD parent record. 
> Hence my confusion about your text.  So I think you meant "This is easily 
> addressed by receivers ignoring the report adivce in the OD parent record."

Yup.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Dec 2018 01:27:03 +0000

On December 12, 2018 3:30:20 PM UTC, Dave Crocker <[email-masked]> wrote:
>....

As written, it doesn't.  If you change it the way you propose, it will.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Dec 2018 17:46:08 -0800

> As written, it doesn't.  If you change it the way you propose, it will.

Please elucidate.  I don't have a guess as to what those issues are.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Dec 2018 23:21:14 -0500

> Please elucidate.  I don't have a guess as to what those issues are.

RFC 7489, Section 9.1 describes the data exposure considerations associated 
with DMARC.  If we extend DMARC with PSD and no limitations on PSO 
participation, then those considerations will apply to every domain that does 
not participate in DMARC (because the PSO can now get the data - publishing a 
DMARC record will prevent that, but let's not make DMARC participating more 
coercive than it already is).

I think it would be interesting to get more details from John Levine on his 
experience with this as he has (in a later message in the thread) mentioned 
he's getting this kind of data now for odd architectural reasons.

Back to this draft, without the registry or some equivalent mechanism, we'd 
have to look at the part of Section 4.1 on Multi-organization PSDs and give a 
detailed explanation of the privacy risks to non-DMARC participants.  It's not 
relevant as the draft is currently scoped because as currently defined it's 
only for PSDs where every domain is required to participate in DMARC, so no 
issue.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2018 08:08:46 -0800

On 12/12/2018 8:21 PM, Scott Kitterman wrote:
> If we extend DMARC with PSD and no limitations on PSO
> not participate in DMARC (because the PSO can now get the data

Scott,

Thanks for the clarification.

Now I understand the nature of the privacy concern:

      (Public) registries that publish a DMARC record will get email
      traffic reports of their customers who do not publish DMARC
      records.

This does indeed seem a new attack surface, since the other powers of 
the registry mostly fall under denial of service rather than traffic 
analysis.

So the provisions of Section 6.1 in the -psd draft are meant to ensure 
that entries in the PSD registry are limited to any registry that:

>    adequately describes PSD policy to require domain owners to use DMARC
>    or that all domain owners are part of a single organization with the
>    PSO.

I suspect that this will have cases that prove rather more challenging 
to the Expert Reviewer than one might expect -- definition of 'single 
organization' can get sticky in some cases -- but still, the nature of 
the requirement is clear:  ensure that registry policy is documented and 
targets DMARC usage explicitly.

(Small point: Given this purpose for the registry, it's probably 
important for the registry's policy document to be publicly available, 
but that's not stated as required.)

Hmmm...

Let me suggest a much easier hack, which differs in utility mostly by 
being post hoc rather than the current draft's pre-hoc mechanism:

      Require the registry to publish another DNS record, in its _dmarc 
node, which a) asserts either than DMARC is required or that the subtree 
is part of a single organization, and b) contain a URL to the 
documentation for this.

A query for the DMARC record of the registry will also deliver this 
information record.  (This might be the first case in which the problem 
of getting 'other' TXT records is actually a feature and not a problem...)

That makes the information public, while avoiding the considerable 
overhead and problems of a new registry -- nevermind one that needs 
real-time querying.

d/

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 13 Dec 2018 08:20:51 -0800

On Thu, Dec 13, 2018 at 8:09 AM Dave Crocker <[email-masked]> wrote:

>
> Let me suggest a much easier hack...
>

> overhead and problems of a new registry -- nevermind one that needs

A link to inscrutable legalese, potentially in a non-interpretable format
(consider, for example, a PDF consisting of images of a foreign alphabet -
perhaps Klingon) doesn't seem to really achieve the intent. And neither
does the bald assertion - "trust me, I require people to do the right
thing" :-)

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2018 08:24:38 -0800

On 12/13/2018 8:20 AM, Kurt Andersen (b) wrote:
> A link to inscrutable legalese, potentially in a non-interpretable 
> format (consider, for example, a PDF consisting of images of a foreign 
> alphabet - perhaps Klingon) doesn't seem to really achieve the intent. 
> And neither does the bald assertion - "trust me, I require people to do 
> the right thing" :-)

And yet the current draft relies on a single 'expert' to be able to 
achieve a productive outcome with exactly the same material.  And it 
produces only a single review at the time of registration.

The benefit of the approach I'm suggesting is that it surfaces these 
documents much more openly and makes it likely they will be reviewed 
much more widely and on a continuing basis.

d/

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2018 13:27:08 -0500

>he's getting this kind of data now for odd architectural reasons.

I'm the legacy registry for seneca.ny.us, a rural county just north of
here.  One of my registrants is the county government, at
co.seneca.ny.us.  I have an MX on seneca.ny.us so people can write to
me at [email-masked] if someone in the county wants to
registers a name.  They have lots of people at
<whoever>@co.seneca.ny.us.  I have my usual dmarc record at
_dmarc.seneca.ny.us, and I've noticed that since they don't publish a
dmarc record (or much of anything else, since their mail is outsourced
to O365 and they're not very sophisticated), I get all of their dmarc
reports.

In this case it's not a big deal, they know who I am, I know who they
are, local governments aren't supposed to keep secrets, and the
reports don't show anything surprising, but one can imagine situations
where it could be an issue.  I suppose in principle it might be a
problem if some of their mail showed up in failure reports, although
since my policy is p=none and as far as I can tell nobody there sends
mail to mailing lists, there aren't many of those.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Dec 2018 19:25:22 -0500

> much more widely and on a continuing basis.

It suffers from what is, in my opinion, a fatal flaw: it relies entirely on 
assertions that any PSO can publish with no external review.  Without some 
kind of third-party check on this, I don't believe there's any privacy 
mitigation at all.  

In previous examples, this has been analogized  to the Verisign sitefinder 
debacle.  Personally, I think it's worse.  Without an external check, this is 
a tool for enhancing the surveillance capacity of authoritarian regimes.  I 
don't find making the documents public so people can complain at all useful.  
The entities that will most want to use this will tend to be the ones that 
care least about complaints.

I'm not claiming an IANA registry is an essential part of the solution, I'm 
sure their are better ideas, it's just the one I thought of.  What we need is 
some location of information about domains that is neutrally managed in 
accordance with open processes.  That sounded like IANA to me, but I'm open to 
suggestions.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2018 20:54:53 -0500

In article <2046741.GJeexbxHFF@kitterma-e6430> you write:
>a tool for enhancing the surveillance capacity of authoritarian regimes.

This is starting to sound like the drunk looking for his keys by the
streetlight.

I grant the hypothetical point you're making, but if I were a cruel
government, funky DMARC records would not be near the top of my list
of intrusive techniques.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Dec 2018 23:17:52 -0500

On Thursday, December 13, 2018 08:54:53 PM John Levine wrote:
> >debacle.  Personally, I think it's worse.  Without an external check, this
> >is a tool for enhancing the surveillance capacity of authoritarian
> >regimes.

Possible, but I come back to as bad as it is, let's not make it worse.

I don't think that domains should have to opt-out (by publishing a DMARC 
record) of having their data sent to the registrar of their TLD/PSD.  If it's 
open season for PSD, then that's the situation we've created.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2018 20:34:35 -0800

> kind of third-party check on this, I don't believe there's any privacy

I think that assessment is misses an essential point.

Let me back up and say that my suggested alternative is intended to take 
the basic concern you are raising seriously.  (I'm not stating a 
personal opinion about the seriousness of this as a threat vector, but 
merely looking for a simpler way to satisfy the concern.)

The alternative requires that the registry's dmarc record be accompanied 
by a record that points to the terms and conditions the registry 
publishes to indicate why their record is acceptable.  (Your draft's 
specification of those conditions looked to me like a reasonable 
starting point; there should be a separate wg discussion for the precise 
details and wording; I don't have a personal opinion about those words.)

As for the benefits I see in the alternative I've proposed, I'll class 
them as simplification and robustness.

First, a new, query-able registry is expensive to run; and difficult to 
ensure quality control for, over the long run.

Second, the vetting method your draft proposes for the registry relies 
on a technical expert to make what is frankly a legal assessment of the 
terms and conditions that the registry publishes.  And that assessment 
is made only one time, when the registry entry is first created.  The 
registry might change its T&C text and we'd be unaware of it.

So while you are technically correct that the alternative means that the 
registry gets to /publish/ with no external review, it is not true that 
their dmarc record will automatically be used without review.

In fact what I'm proposing will make widespread and ongoing review 
likely, IMO, probably in the spirit of ongoing reputation assessment 
that the email industry already does, although for dmarc default record 
rather than spam.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Dec 2018 16:22:17 +0100

On Thu 13/Dec/2018 17:08:46 +0100 Dave Crocker wrote:

> Let me suggest a much easier hack, which differs in utility mostly by being
> post hoc rather than the current draft's pre-hoc mechanism:
> 
>      Require the registry to publish another DNS record, in its _dmarc node,
> which a) asserts either than DMARC is required or that the subtree is part of a
> single organization, and b) contain a URL to the documentation for this.
> 
> A query for the DMARC record of the registry will also deliver this information
> record.  (This might be the first case in which the problem of getting 'other'
> TXT records is actually a feature and not a problem...)
> 
> That makes the information public, while avoiding the considerable overhead and
> problems of a new registry -- nevermind one that needs real-time querying.

+1.  The documentation is going to be consumed by MTA admins who decide whether
to honor the rua= request or not.  A community reviewed distributed registry.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 15 Dec 2018 01:23:32 +0000

>that the email industry already does, although for dmarc default record

I see your point.  In addition to complexity, tohe issue that there is no mechanism for removing bad actors from the registry does present a problem.

Let me think it over and see if I can come up with text that both addresses your concerns and also provides guidance that I'd be comfortable with in lieu of the registry.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 17 Dec 2018 15:03:36 -0500

On Saturday, December 15, 2018 01:23:32 AM Scott Kitterman wrote:
> >> It suffers from what is, in my opinion, a fatal flaw: it relies
> >
> >entirely on
> >
> >> assertions that any PSO can publish with no external review.  Without
> >
> >some
> >
> >> kind of third-party check on this, I don't believe there's any
> >
> >privacy
> >
> >> mitigation at all.
> >
> I see your point.  In addition to complexity, tohe issue that there is no
> mechanism for removing bad actors from the registry does present a problem.
> 
> Let me think it over and see if I can come up with text that both addresses
> your concerns and also provides guidance that I'd be comfortable with in
> lieu of the registry.

I thought about it over the weekend, and I didn't come up with anything I was 
really happy with that also addresses your concerns.  Still thinking about it.

It is clear though, based on this discussion, that the privacy concerns 
section needs to be beefed up.  My plan is to focus first on that.  It has two 
advantages: One; I think I know what to write and two; I don't think it will 
be very controversial.

In any case, having agreed text in the draft that describes what privacy 
issues we want to mitigate seems like a good next step towards figuring out 
how best to do that.

Scott K