Re: [dmarc-ietf] PSD simplification

[Dave Crocker <[e-mail]>]

On 12/12/2018 8:59 AM, John Levine wrote:
> In article <[e-mail]> you write:
>> 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.
> 
> 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.

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,
 > but not which subdomain.

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


> 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.

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?


> 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.

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/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net