Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely <[e-mail]>]

On Wed 14/Aug/2019 04:01:59 +0200 Dave Crocker wrote:
> 
> 
> Review of:    DMARC (Domain-based Message Authentication, Reporting, and
>               Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:          draft-ietf-dmarc-psd-06
> Reviewer:     D. Crocker
> Review Date:  12 August 2019


I like very much Dave's prose, especially the background.  I hope
large fragments of it will make their way to either the PSD draft or
the reviewed DMARC spec itself.

For brevity, however, I only quote the passages I comment on:


> This approach is problematic in several ways.
> 
> It is a substantial increase in DMARC's operational overhead.  It adds
> a query that will often be needed -- especially in the face of limited
> DMARC adoption.  If a domain is not already a 'popular' DMARC
> reference -- that is, frequently encountered by the querying site --
> it is likely that there will be no DMARC record for any of the three
> needed queries. That means a 50% increase from two (failed) DNS
> queries to three (failed) queries.


That's actually a bit better.  After the second (failed) query, the
receiver consults the "augmented PSD".  IMHO, the latter should be a
local lookup, just like the PSD itself.  The third query is only
issued if the prefix matches.  Then, the likelihood that it fails is
very low.


> Arguably for DMARC purposes, an association domain can be treated the
> same as an organization domain, since the scope of the domain's
> authority over its sub-domains is an internal matter, to be determined
> by its agreements with association members.
> 
> What this means is that the real requirement here is to improve the
> mechanism for identifying the organizational domain, and that
> requirement is outside of DMARC.  This does not reduce the necessity
> of identifying these domains; rather it moves the task to where it
> belongs: This requires modification to the public suffix list
> operation, possibly with a parallel "private TLD" registry.


Right.  However, consulting the augmented PSD still has to be done in
two steps, the first one to give the organizational domain a chance to
override the association domain policy, the second step if no override
was published.

Let me add that the relevant case is NXDOMAIN.  For existing domains,
the association can see if a lazy organization misses a record and
force them to comply.  However inconsiderately, the association could
even publish itself a txt record at _dmarc\.lazy.example.  The
annoyance is trying wildcards to cover any non-existent domain name.


> An added benefit to this alternate view is that it eliminates the
> privacy concern about the draft specification:  only upper-level
> domains operating as organizational domains will be able to publish a
> domain-wide DMARC policy record.  Domains that really are classic
> public suffixes won't be able to.


Certainly, A.bank and B.bank shall not be conflated as far as
exchanging cookies and access rights is concerned, so a fine-grained
PSD will continue to exist.

I'm not sure flattening that structure for DMARC is a benefit.  By
skipping the second query, we'd deny organizations the possibility to
have subdomain email addresses like [e-mail], unless
branch.A.bank either replicates or overrides the DMARC record of A.bank.




Best
Ale
--