Re: [dmarc-ietf] PSD simplification

[Scott Kitterman <[e-mail]>]

On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
> 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?

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